Re: HTTP client module

Florent Georges wrote:
> John Snelson wrote:
>> Florent Georges wrote:
> 
>>>   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.
> 
>   But the point is not the parsing itself (well, that's not the main
> point,) but the connection.  If the extension does know it doesn't need
> the body, it can close the connection after the headers have been
> received.  Without that knowledge, it will have to keep the connection
> open and receive all the HTTP response.

Good point.

>> 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.
> 
>   Well, do you really think there's a significant added complexity?  I
> do not think, neither for the user nor the implementer.

It may not be a significant complexity, but it still outweighs the 
benefit IMO.

>   BTW, if I understand correctly, because you tell you don't need to
> keep the response buffers, we are not talking about lazy evaluation,
> but instead about static analysis to determine if an item will be ever
> used or not.  If there is any doubt, even with lazy evaluation, you
> will need to either evaluate the item or keep the response buffers in
> memory, won't you?

I'm not talking about static analysis, but that's a way that it could be 
implemented. The thing is, most often there isn't any doubt about how an 
expression result is used.

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