- From: Jim Ley <jim@jibbering.com>
- Date: Sat, 15 Nov 2003 16:09:01 -0000
- To: www-svg@w3.org
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