gimoya / florawebscraper Goto Github PK

It may appear to be a style question to some, but for me it is more of a small necessity; the integration of a time delay in an automated online request loop, be it a scraper or a request-series over an application programming interface (API), e.g. google API, or anything else.

This idea is based on the care for scalability of the script. If just a few people use the script, it should be no big deal for the webserver, but I really do not know what the result would be, if many website requests were fired off in high frequency :-) through many scripts. Weighing the benefits I gain from lovely scraping scripts like this, it may really pay off, and be even seen as a kind of gesture of respect towards the website (floraweb, OK it is a filthy governmental website, so maybe .... but then again, I think they really present a wide collection of not so bad botanical information, I myself am surprised ... ) .

Coming back to what I started with, it really is basically a style question, but from my point of view, should not be, but more than that a matter of responsability for the script, to ensure scalability towards high-usage-compatibility.

I would, if I may continue on such maybe touchy issue, consider something like a 1 second gap to be a really OK time for a delay between the requests.

Therefore adding a Sys.sleep(1) within the main_function could be pondered upon, and I think, as stated before, really does not hurt. More accurately; to really not spend more time than 1 second for one request would be to get startTime <- Sys.time() in the beginning of main_function and get endTime <- Sys.time() at the end again, build the difference diffTime <- (endTime - startTime)[[1]] and then work with that to determine whether a sleep time could be considered, and if so, how much. This could, all in all, look something like this;

main_function <- function(x) {
startTime <- Sys.time()
...
...
endTime <- Sys.time()
diffTime <- (endTime - startTime)[[1]]
if(diffTime < 1){Sys.sleep(1-diffTime)}
}

Please, let me know what you think. I am not sure, if this is just a question of preference, or matters to the functionality of the code - therefore I was hesitant to actually post this suggestion.

Greetings

I just found out, that you could solve the encoding problems (e.g. umlauts äöü displayed wrongly) produced withing the urlParse by adding the option encoding = "UTF-8" to the urlParse functions. To elaborate shortly; htmlParse(URL) would become basically htmlParse(URL, encoding="UTF-8"). (The same applies of course for the second time htmlParse is used..). I tried it, and it should solve the problem with the otherwise produced strange symbols, I experienced before the fix, that must have resulted from a unsuitable encoding default of the htmlParse function I infer. With adding the encoding option, your workaround spch_sub could be left out of course.

I find your script very helpful, many many thanks for your excellent work! Maybe this small change, I suggest, could improve the scraper.

Greetings from Lüneburger Heide, Germany

(Another minor issue I will post separately for keeping things clear in github.)