Re: HTTP client module

Florent Georges wrote:
> John Snelson wrote:
> 
>>> To summarize: Never assume anything more than compliance with
>>> the W3C specs.
> 
>> I'm not assuming that. All I'm saying is that if you care about 
>> efficiently evaluating part of a sequence, you go with a lazy
>> evaluation strategy
> 
>   But the recommendations do not require lazy evaluation, not
> mentioning the ability for an extension to be able to provide it.  I
> think relying on extensions being able to provide lazy evaluation in
> every processor is not reasonable in EXSLT.

I'm not suggesting we rely on it - I'm just suggesting that we remove 
the status-only option and say nothing about efficiency. The worst that 
could happen if an implementation doesn't provide lazy evaluation is 
that a little extra parsing happens, which is not exactly a big deal.

>   And even if you could, I am not sure it would be a good think. 
> Because that's not about lazy evaluating a pure functional expression,
> but analyzing an HTTP response.  So it would mean to keep the HTTP
> response buffers as long as the items are in scope...

XQilla wouldn't need to, and I suspect other implementations wouldn't. 
In any case, the HTTP response is probably smaller than any parsed 
representation of it.

I just don't see the point of adding the implementation burden of 
another function option to http-request() because it solves a /possible/ 
efficiency problem that XQuery and XSLT 2.0 implementations are already 
fully capable of solving without the option.

John

-- 
John Snelson, Oracle Corporation            http://snelson.org.uk/john
Berkeley DB XML:            http://oracle.com/database/berkeley-db/xml
XQilla:                                  http://xqilla.sourceforge.net