5 ms·
I think this is a neat proof of concept. However, you have to be extremely careful to not get out of sync hell. I see an enormous load of extra complexities fo
by pothibo 13y ago
I think this is a neat proof of concept. However, you have to be extremely careful to not get out of sync hell.
I see an enormous load of extra complexities for what seems to be very little advantage.
On the other hand, if you list all the queued non-GET AJAX call for the user to resend manually, it could be good.
I'm ambivalent :(
- rmrfrmrf 13y agoWhy are you critiquing this script like it's a consumer product? Obviously any developer who wishes to use this will have do some extra work to make sure things run smoothly.
- pothibo 13y agoMaybe because I've already implemented something like this in the past and I faced a lot of issues with synchronizing multiple states on multiple devices? And I didn't say the library was bad, quite the contrary.
- zackbloom 13y agoI wrote the js in Offline. I agree completely, this is definitely not an attempt to resurrect Google Gears. I would love to see how more people use it, and what sorts of problems they run into before deciding what the solution might be. Two thoughts right now (make a gh issue if either is something you need): - Make an option to only enable request remaking for GET requests - Make an option to throw out POST/PUT/DELETE data if it's more than X minutes old Listing the requests is interesting, but would obviously require the programmer to associate the request with the user-facing feature it enables. Something like messenger might be better for that: http://github.hubspot.com/messenger/ http://github.hubspot.com/messenger/
- pothibo 13y agoThanks for the library and I'm glad you understand what I tried to say. The warning I was giving was not meant as criticizing your library. It was meant as a general warning when dealing with queueing ajax request when offline.