Re: HTTP client module

John Snelson wrote:

  Hi John,

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

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

> In any case, the HTTP response is probably smaller than any
> parsed representation of it.

  Which doesn't mean it is small ;-)

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

  And once again, I do not see how an implementation can at
the same time lazy evaluate the item and not require to keep
the response body buffers in memory till the first use of the
item or till its scope ends.  I maybe missed something though.

  Regards,

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