[SVG 1.2] 17.6 Better network data interface

Hi,

I'm not sure I understand this interface, or it's useless, one or the other,
hopefully I don't understand it.

The Request/Reply objects seem heavily biased towards HTTP, yet the example
shows non-http network events being used.

Why is there a get( ... ) shortcut ?  What headers does it send by default,
should HTTP cookies be sent along with the request, always/sometimes/purely
controlled by the user?  Should other headers add by the UA to regular HTTP
requests (perhaps used to inform proxies) be added, or not, if they're
added, what happens if the script attempts to set the same?

When HTTP data arrives, how does the SendData event get fired, only at the
completion of the data, after the headers have arrived but then in various
chunks up to the UA, are the headers then persisted or what?

So, I'm a bit confused with the HTTP binding, it seems incompletely
specified and not terribly useful - I don't even see how to perform a POST
or a PUT within the framework, or indeed anything but a GET.

For non-HTTP protocols I don't understand it at all, how does IRC work for
example, the protocol is quite simple, but I can't see how it fits in with
the described syntax, the example used is meaningless (where does it say
which user to be, how do we send messages to the IRC server etc. ?)  The FTP
one, again, where's the login authentication etc.

The TCP raw one may be meaningful, and useful, but this then has null's
being sent everywhere, something which is neither neat, nor convenient for
developers (in ecmascript methods not passing anything is the same as
passing null, scripters expect this - but they generally don't get this
conveniently with DOM methods)

My recommendation is to do away with the HTTP specificness, just provide a
simple TCPRaw version, where the author can work on the other details, ie
just create a socket, send data down it one way, have data come back the
other the SVG implementation need know nothing more about the protocol than
the TCP level.

Due to the importance of HTTP, we can then provide a more elegant HTTP
interface, and here, the relevant one is the XMLHTTPRequest object as
already implemented in Mozilla and Internet Explorer.  Not inventing a new
hodge podge network interface to no-ones advantage.

Jim.

Received on Saturday, 15 November 2003 11:10:02 UTC