Load - caches and so forth?

[Dave Cragg]

On 28 Apr 2006, at 18:21, David Bovill wrote:

> Dave Cragg wrote:
>> I'd be wary of trapping geturl. This is a handler inside libUrl  
>> that gets called directly by the engine, and it contains some  
>> irregular syntax.
> Yes - what is:
>
>    return  empty  with cachedUrl laLoadedUrls[newUrl]
>
> when it is at home?

David, you're only the second person to ask me that question. And the  
first on this list. That deserves something, an answer at least.

When I started looking after libUrl, I was told what the syntax did.  
When I asked *how* it worked, I was told by Scott Raney, "It's  
magic." I left it at that. The alternative was to roll up my pants  
legs and make strange incantations.

However, you''ve probably noticed that engine calls can return  
something different in both the "it" variable and "the result".   
(e.g. read from file etc.) But you can't make your own handlers  
behave that way. "get url" (and similar calls) were once handled  
inside the engine. When it was decided to do the http and ftp  
routines though a script library, I guess some trickery was required  
to make sure the engine calls still worked as before.

In addition to dealing with "it" and "the result", the syntax  
performs another piece of magic. libUrl stores the data returned from  
url calls in a script local array. For "get url" calls, it has to  
return the data and empty out the data from the array. If you've ever  
had to do this from you own script library, you'll know you normally  
have to first copy the data from the script local to a handler local,  
then delete the script local, and then return the data. For large  
chunks of data, that's a lot of data copying. libUrl is privileged in  
having the script local emptied for it by the engine after it  
returns. However, as "load" has to preserve the data, the "cachedurl"  
part of the syntax lets the engine know whether it should clear the  
script local or not.

You did ask. :-)

Cheers
Dave