Retry failed load - feature request

[Philip Bulley]

I'm not fully up to speed on all of the features of LoaderMax, but it doesn't look like there's any obvious 'retry after failed loader' mechanism. So unless I've missed it, this is a feature request

 

Maybe specifying { retry:3, retryDelay:10 } would tell the loader that in event of failing, the loader would retry up to 3 times before dispatching a fatal error. It would wait 10 seconds between the failed load and trying again.

 

It'd also be good to be able to call something like loader.retry(), for the scenario where the loader has completed, but the data returned fails a custom validation check (for example if an API decides to limit your access and sends you XML containing an error message, but with an HTTP 200 OK response header, in which case you might like to retry after a certain period).

 

I guess if progress events could report all of this too, that'd be good.

 

Any thoughts?

[GreenSock]

I certainly considered the "retry" feature, but I decided against adding it for several reasons:

 

1) It almost never helps. Typically if a file isn't found, requesting it again won't suddenly make things work. If the server is down, there's a very small chance it will come back online by the next retry, but that's quite unlikely in real-world situations.

 

2) It's non-standard behavior. Web browsers don't do this sort of thing either. Imagine if when an image didn't load, your browser kept requesting it multiple times from the server and delayed rendering the page fully until it finished all of the retries. That would make for a pretty annoying user experience. I understand why it makes sense from the developer's perspective - you want all the files loaded, but the real-world benefits of a "retry" feature are very limited and introduce more hassles and delays (in my opinion) than are worth it.

 

3) It delays things too much. Imagine a scenario where you've got a LoaderMax with a queue of 10 images to load and image #2 fails. Do you really want the queue to be held up, not dispatching its COMPLETE event until it has waited 10 seconds...retried....waited another 10 seconds...retried, etc.?

 

4) File size. I tried very hard to keep things tight and efficient while being feature-rich. It's a balancing act, but frankly I didn't see enough practical benefit to an automatic "retry" feature to justify the extra kb it would cost. I talked to several other developers about this too and they agreed that the automatic "retry" feature isn't a worthwhile addition.

 

By the way, there is an "alternateURL" special property that you can define to have your loader automatically switch to another URL if the original one fails. That seemed like a much more useful, practical feature (to me at least).

 

If you want to retry, you can certainly listen for the FAIL (or CHILD_FAIL) event and implement it yourself. This ties into your second question/comment/request - you can use the "flush" parameter of the load() method to force a full reload, dumping any contents that were already loaded and loading again. So it would look like myLoader.load(true).

 

Does that address your concerns adequately?

[Philip Bulley]

Hey jack,

 

I didn't notice your reply here until now. I originally figured that a retry feature would be useful when calling API methods, rather than static files. As an API method can often return a response that isn't adequate (for example, during twitter's rate limiting). But I totally understand and appreciate each of your points, and agree that this functionality is probably so niche that it's best implemented outside of LoaderMax itself.

 

Cheers,

Phil