Re: SVG 1.2 URLRequest interface

Michael,

Thank you for the feedback. We discussed it at SVG WG teleconferences and 
here are our comments.

At 10:37 AM 8/20/2004 -0700, Michael A Nachbaur wrote:

>Hello everyone,
>
>I have to admit that I've never used SVG before, though I eagerly 
>anticipate it's adoption in Mozilla (implementation issues 
>notwithstanding).  I also have to apologize in advance for a rather 
>lengthy email.
>
>The reason I've joined this list is due to the URLRequest interface being 
>defined as part as SVG 1.2.  I'm a XUL application developer, and use 
>XMLHttpRequest quite extensively.  Knowing this, Robin Berjon pointed me 
>to http://www.w3.org/TR/SVG12/#urlrequest-interface.
>
>After reading the spec - and realizing that a standardized replacement for 
>XMLHttpRequest was in the works - I bolted down the definition for it, and 
>instantly had half a dozen requests to make.

Yes, we indeed modeled URLRequest after XMLHttpRequest, it is designed to 
be basically just as simple to use with just a little bit of extra power. 
Everyone who used XMLHttpRequest or IE's MS.XMLHTTP should feel right at home.


>Now, I understand that this interface is being developed as part of this 
>spec for temporary reasons (Robin filled me in on the details), but I'm 
>*excited* about the possibility of this functionality becoming available 
>in XUL.  The native XPCOM interfaces for invoking and manipulating HTTP 
>requests tend to be a bit heavy-weight, while XMLHttpRequest is IMHO 
>vastly underpowered and clunky.
>
>1) I notice that there is an interface defined as NameValuePair, which is 
>returned as part of the getResponseHeader() method.  If there isn't a need 
>to use this object in other aspects of the spec, perhaps this could be 
>named "URLHeader"?  That way it could be subclassed to create things like 
>"URLDateHeader" or "URLEncodedHeader", to encapsulate the logic necessary 
>to handle things like www-form-encoded encoding.

That's a good suggestion and SVG WG accepted it.


>2) One of my biggest beefs with XMLHttpRequest is the fact that it's one 
>object, while HTTP itself is inherently divided into two parts: Request 
>and Response.  When you issue a request, the XMLHttpRequest object itself 
>is changed to reflect the result of the response.  This is fine when you 
>want to extract content from an HTTP response, but this model falls flat 
>on it's face when you want to use pipelined HTTP requests.
>
>If I want to issue the same HTTP request repeatedly (for instance, 
>processing a queue, or checking the status of an asynchronous operation), 
>one subsequent invocation of the .open() method will overwrite the 
>response of the previous invocation.
>
>It seems to me it would be much more useful if the getResponse() method 
>would return a URLResponse object, which contains the status, response 
>headers, XML and text bodies, etc.  This way, I could re-issue the 
>request, with exactly the same parameters (or, for instance, just changing 
>query arguments), and get a second response object representing that request.


This poses some design problem. While HTTP transaction is divided into 
Request and Response, every Request is tightly coupled with Response. So, 
if we were to split this interface like that, we'd have to have a response 
field on a request and request field on a response. If request can be 
reissued before it completes, though, it breaks the coupling which is 
inherent in HTTP (and many other protocols) on the API level. The result 
seems to be confusing to the user. For instance, what should request filed 
of response say if the request was reissued before a response has arrived? 
What cancelling a request that was reissued does? Given these problems and 
the fact that _all_ widely used browsers implement this feature along the 
lines of XMLHttpRequest (i.e. monolithic object), we decided against splitting.

Also, funny enough, early drafts of this API did contain a split 
Request/Response classes 
(http://www.w3.org/TR/2003/WD-SVG12-20031113/#network-data) and some people 
were saying that they should be joined, "just like all browsers do" - to 
some extent, that's a matter of taste; someone always gets unhappy.

However, to address your specific (and very valid) issue we have decided to 
add cloneRequest() method that can be used to create another copy of 
pre-populated request easily. UAs can implement it just as efficiently as 
request re-issue by simple copy-on-write strategy - so it seems like the 
best of both worlds.


>3) With some HTTP content-type encoding schemes, it is possible to send 
>multiple content bodies within a single HTTP response (e.g. file 
>uploads).  I have never actually tried to do this myself, but would it be 
>possible to implement this behavior in the spec?

Yes, to some extent this is solved by addContentFromFile which is discussed 
a little bit later in the spec: 
http://www.w3.org/TR/SVG12/#urlrequest-additions

Thank you again for the feedback.

Peter Sorotokin
Member of SVG WG
Adobe Systems Inc.


>These are just a few things I can think of right now, but would save me a 
>*lot* of effort in the long run.  I know people try to prevent "Object 
>Creep", but I feel in this instance making the process of requesting HTTP 
>content represent the structure of an actual HTTP request would help me 
>among many others.
>
>--
>Michael A. Nachbaur <mike@nachbaur.com>
>http://nachbaur.com/pgpkey.asc
>
>

Received on Tuesday, 28 September 2004 00:24:18 UTC