SVG 1.2 URLRequest interface

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.

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.

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.

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?

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 Friday, 20 August 2004 17:38:28 UTC