lubURL nuances

[Dave Cragg]

On 11 Mar 2010, at 13:23, Richard Gaskin wrote:

> While working with Dan Friedman to diagnose some FTP issues, he came up with some questions I couldn't answer so I'm bringing them to y'all to see what we can find:
> 
> 1. Is "put url..." a blocking command?
>   I believe it's supposed to be, but find I can sometime do other
>   things while it's running, including submitting subsequent
>   "put url..." commands.

Jeffrey's post answers this.

> 
> 2. In such a circumstance, the second attempt to "put url..."
>   meets with an error, "Previous request not completed."  I've
>   found that once that error hits the original request sometimes
>   runs into trouble, requiring me to use libUrlResetAll and
>   try again.  Is there a more graceful way to handle that error?

While the error message is correct, I don't know why it should affect the previous request. The only possible cause I can see is the way the error is returned from libUrl. It uses some unusual syntax which is only available to libUrl. ( return "error Previous request not completed" with empty) The engine handles these return statements, and depending what follows the "with", it may do some clean-up. (deleting script variables to avoid the script having to copy the variables before returning). So perhaps something goes wrong at times and it deletes when it shouldn't. (This is pure speculation.)

But if you're using "get url" or other "blocking" calls, I'd suggest you try to prevent users (or your script) from making subsequent calls until the get has returned. Disable the user interface, etc.


> 
> 3. libUrlResetAll comes with a warning not to use it. :)  But I've
>   found it the simplest, most reliable way to cancel all socket
>   activity and start fresh.  If that's your goal, to reset all
>   socket stuff and start fresh, is there some downside to using
>   libUrlResetAll that I've overlooked?

It will reliably close *all* sockets and delete all script variables in libUrl. The consequences of closing all sockets is clear enough. The deleting of script variables is less clear. I haven't tested this in recent engine builds, but it used to be that those variables weren't always immediately deleted. I'm guessing the engine waited for an idle to do the deletion. So if you had something like the following within a handler:

1.  get url someUrl
2.  libUrlResetAll
3.  get url someOtherUrl

line 3 might start the url call but fail when its script variables were suddenly removed in the middle of its activity. So if you're going to use it in your scripts, be sure there's a pause of some kind before making subsequent url calls.

Cheers
Dave