Re: HTTP client module

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.

> 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.

  Great!  But this extension is not aimed only at XQilla ;-)

  And I am sure there are cases where this is not realistic to
determine if the item is actually used or not (because of the cost of
the info.)  Of course, if the attribute is not set, the processor can
use lazy evaluation.

> 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.

  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?

  Regards,

-- 
Florent Georges
http://www.fgeorges.org/