Re: HTTP client module

Florent Georges wrote:
> John Snelson wrote:
>> 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.
> 
>   We do not agree then.  When you send a GET and you are only
> interested by the headers in the response, but the resource
> identified by the URI is a file of dozens or hundreds of Megs,
> that's not only a detail.  That can add several minutes to the
> evaluation time of a stylesheet/query.

In that case, why not use override-content-type to return the body as a 
string and avoid the cost of parsing.

>>> 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.
> 
>   Well, I am confused.  You want to lazy evaluate the item
> representing of the body content of the HTTP response.  So
> when the item is accessed, you have to build it, so you have
> to still get the response content, haven't you?

Yes. But XQilla is good at knowing that you'll never need the second 
value, and at that point getting rid of the suspended evaluation.

>> 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.
> 
>   I think the benefit of being able to ignore the response
> content has been illustrated by M. David P., I wouldn't say
> /possible/.

It's not that I think think there isn't a benefit. I just think that the 
benefit is outweighed by the cost of complexity.

Why burden the user with having to understand the option and then work 
out when the body is needed or not? Why burden the implementation with 
the code needed for the option? A good implementation can easily use 
lazy evaluation or static query analysis to solve the problem.

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