Re: HTTP client module

M. David Peterson wrote:
> Hey John,
> 
> Interesting comments. My follow-up to your comments follow inline below.
> 
> Florent: /GREAT/ to see you taking the initiative on this badly needed 
> extension function!
> 
> On Tue, Jan 20, 2009 at 6:25 AM, John Snelson <[email protected] 
> <mailto:[email protected]>> wrote:
> 
>     Hi Florent,
> 
>     In general I really like this proposal. I've got a few comments or
>     questions below:
> 
>     1) What about adding an alternative function signature with only the
>     $request parameter?
> 
> 
> +1: Providing a "call-back" function for processing the result would be 
> helpful, /especially/ when passing state via parameters.

Callback functions aren't really an option without adopting some kind of 
first class functions. I'm not convinced of the merits of callback in 
this case.

>     2) Shouldn't the $serial accept the name of a set of serialization
>     parameters defined by xsl:output, 
> 
> 
> It does, doesn't it? i.e.:
> 
>         If this is an XML media type, it is serialized using the
>         parameter |$serial|. This parameter can be an |xsl:output|
>         element, as defined in [XSLT 2.0]
>         <http://www.fgeorges.org/xslt/exslt2/http-client.html#xslt20>,
>         and the serialization is defined in [XSLT and XQuery
>         Serialization]
>         <http://www.fgeorges.org/xslt/exslt2/http-client.html#xserial>.
>         |$serial| can also be a string, either '|xml|', '|html|',
>         '|xhtml|' or '|text|' (other values are implementation-defined,
>         as explained in the above mentioned recommendations.)
> 
> 
>     as well as possibly an inline xsl:output element?
> 
> 
> Inline?

I think the proposal is unclear here. To me, it says that you can either 
pass the 4 strings ("xml", "html", etc.), or you can pass an xsl:output 
element, ie:

http:send-request($uri, $content, $request,
   <xsl:output method="xml" omit-xml-declaration="yes"/>)

I've seen people propose adding the above way of giving serialization 
options, since they can then be decided dynamically. I think that's 
interesting, but not essential. I think the ability to reference a named 
xsl:output element /is/ essential though.

>     3) What is the use case for send-authorization? Why not just send
>     authorization in the first request?
> 
> 
> I would assume for reasons of efficiency for sending non-authenticated 
> requests?

I would imagine that if the user requests authentication, it would be 
more efficient to send the authorization credentials in the first request.

>     4) I think that the default serialization method needs to be a bit
>     more flexible - consider application/rdf+xml for instance.
> 
> 
> Unless I'm missing something the default serialization method seems to 
> be as flexible as it can be using named xsl:output elements combined 
> with the default xml, html, xhtml, and text output serialization formats.

Section 3.2 says that the default serialization mode is based on the 
content-type of the message body:

"'xml', 'html' and 'xhtml' are the default for corresponding media 
types, and 'text' for other media types"

Now xml has two well known media types ("text/xml" and 
"application/xml"), but there are a number of media types that use XML 
but might not be considered "xml" media types ("application/rdf+xml", 
for instance).

Whatever is intended, this needs firming up in the proposal.

>     5) What is the use case for status-only? Can't lazy evaluation
>     achieve the same thing? 
> 
> 
> Not sure, but I can /definitely/ see several use cases in which the HTTP 
> response code is all that's required in return to determine what to do 
> next, allowing you to drop the response body for reasons of efficiency.

In that case, lazy evaluation should be sufficient for efficiency. 
Results that aren't needed won't be evaluated.

>     Could you use a HEAD request instead?
> 
> 
> Not if you PUT or POST content.  An example use case: POSTing content to 
> a server in which the HTTP response status code is all that's required 
> to determine if the POST was successful and what to do next.

True.

>     6) "If the body media type is a textual type" - what does that mean?
>     What about text/xml?
> 
> 
> Isn't this a fairly well understood distinction in which a textual media 
> type represents any non-(XML)structured string (i.e. escaped (X)HTML, 
> base64, etc.), text/xml representing non application specific XML (AKA 
> Plain Ol' XML), and application specific XML being specified as such 
> using the "application/foo+xml" mime-type prefix/type-suffix format, all 
> specified in the Content-Type request/response header?

Can you point to a specification where a "textual media type" is 
defined? If not, then this specification needs to define it. My thoughts 
were that the most obvious definition would be a media type that started 
with "text" - but then what about "text/xml".

>     7) Should HTML parsing (tidying) be optional?
> 
> 
> +1: Serializing an HTML string as-is in the output should be supported 
> by default.

I think you misunderstand - I'm wondering if it should be changed to be 
optional. My thoughts are that that HTML parsing into an XML infoset is 
a subjective process, and libraries to do such things might not always 
be available. I do think it's very useful functionality, though.

>     What about parsing other media types - could that also be
>     implementation defined?
> 
> 
> Isn't that handled already via:
> 
>         If the attribute |override-content-type| is set on the request,
>         its value is used instead of the content-type returned by the
>         HTTP server
> ?

No. I want the ability to return an XML representation of JSON if the 
mime type is "application/json", for instance.

My understanding is that "override-content-type" will only allow me to 
tell the implementation to treat (for instance) a response with mime 
type "image/jpeg" as "application/xml" and try to parse it. That sounds 
dangerous to me, so I'd like a good use case for having the functionality.

>     8) What is the use case for "override-content-type"?
> 
> 
> See above?
> 
>     9) What about the ability to send base64Binary, or hexBinary? I
>     guess that would involve a binary serialization method.
> 
> 
> That's handled via MIME multipart: 
> http://en.wikipedia.org/wiki/Multipart_message#Multipart_messages

What I mean is, if I have an item of type xs:base64Binary, how can I 
send that as a binary payload in an HTTP request. Even if multipart-mime 
  supports that, the http:send-request() function also needs to support 
that.

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