URL download and Cache problems

[Dave Cragg]

On 16 Dec 2004, at 08:56, Chipp Walters wrote:

> Dave Cragg wrote:
>
>> Richard's thought may stem from a similar experience to mine. 
>> Previously, "load" was often preferred because it was the only way to 
>> show  progress of the download, and not because there was a need to 
>> do other processing. In my own apps, I almost always need to pause 
>> other things until a download completes. (e.g. a learner chooses a 
>> lesson to open, and can't work on it until it has downloaded) "load" 
>> wasn't ideal for this. But "load" was often recommended over "get" 
>> because of this ability to show progress. With the 
>> libUrlStatusCallback option, I now rarely need to use load. It's much 
>> simpler to use get.
>
> I love libUrlStatusCallback! It also works great with POST and ftp 
> uploads/downloads.
>
>> Caveat:  when using "get", there's no obvious way to abort a download 
>> before it completes. This should probably go on the to-do list.
>
> In my apps, I issue 'resetAll' which stops the download. Dave, you 
> once mentioned a command something like libURLResetAll? I think it 
> does the same thing.

Then it's detention for you, Chipp. :-)

All "resetAll" does is call libUrlResetAll. liburlResetAll is the 
"preferred and official" command. (Because there's a high chance 
someone has a library or stack script with a resetAll handler which 
does something completely unrelated, but more understandable such as 
resetting a set of preferences to their defaults.)

> Then I need to reinitialize my libUrlStatusCallback. This can present 
> problems when calling from the IDE as it kills all socket activity for 
> the engine everywhere, so best be careful.

Be very careful! libUrlResetAll is a particularly brutal way to stop a 
download. I don't recommend it to anyone. For me, it's just a 
development tool and never include it in a distributed stack. But if 
anyone feels the need to include it in an app, be sure that 
libUrlResetAll is the last libUrl call in the handler where it appears.

But until I add an official way to cancel a "get" download, here's a 
little tidbit. You can cancel a download by using this command:

   ulCancelRequest <url>

This is an internal handler used by libUrl during the "unload url" 
procedure. This handler alone should happily stop a "get" request too.

WARNING:  If you use this in a stack, be prepared to change it when a 
future libUrl release adds an official interface.

Cheers
Dave