Charles Warwick wrote: > I would like to resolve as many libUrl reliability issues as possible > in the community edition as well. > > Having worked on the tsNet libUrl wrapper, I have some ideas about > what is going on but what always helps is a sample script that can > reproduce the problem.
Thanks for your interest. I've modded my libURL and have been experimenting, will deliver a sample stack soon.
Thus far I've found that your libURL function is much more reliable than the recommended flag option, but still problematic in some cases unless I slow things down with the introduction of an otherwise-unnecessary wait.
Chipp Walters uses a brute-force method since picked up by Jacque and others in which he calls libURL in a repeat loop until it returns a meaningful result. Sad to have to work that hard.
At the heart of why so many people seem to be having problems with libURL is that the so-called "blocking" form only blocks the current execution instance of the handler calling libURL. Messages still happen, any handlers that are calling libURL are re-entrant, and that's where people are seeing blocked connections, engine hangs, and occasional cursor locking (WTH is up with that?).
The ideal solution would be for an option to have true blocking, without the semi-quasi-difficult-to-predict-exactly-what's-happening form of threading in place for the so-called "blocking" form offered currently.
Those who need non-blocking can use "load url". Works fine, at least for GET.
Maybe the issue is that POST doesn't currently have a non-blocking form, so the design in place now attempts to hit some mystifying middle path between true blocking and truly async behavior, hitting neither quit spot-on.
I'll continue my experiments with various permutions, including Chipp's now-famous hammer-on-it-until-it-behaves option, and see if I can come up with something that doesn't require slowing down the workflow with an otherwise-unnecessary wait statement.
It's not a long wait (right now the shortest wait that prevent hangs is around 250 ms), but the issue of preventing re-entrance remains a challenge.
I may wind up keeping a checksum hash of the url + POST data, monitored in a timer to prevent duplicate attempts from happening too close together. Seems a lot of work, though, for something where the code would be MUCH simpler if we only have a truly blocking GET and POST option.
-- Richard Gaskin Fourth World Systems Software Design and Development for the Desktop, Mobile, and the Web ____________________________________________________________________ ambassa...@fourthworld.com http://www.FourthWorld.com _______________________________________________ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
