- From: Jim Ley <jim@jibbering.com>
- Date: Sun, 31 Oct 2004 11:57:30 -0000
- To: www-svg@w3.org
"Ian Hickson" <ian@hixie.ch> wrote in message news:Pine.LNX.4.61.0410310836350.15175@dhalsim.dreamhost.com... >> B.1 SVGTimer Interface > > This interface appears to be a more complicated version of the widely- > implemented window.setTimeout() and window.setInterval() methods. I > would recommend not reinventing existing interfaces, since these > interfaces are well understood and easy to specify and use. They are not well understood, consistently implemented, or architecturally sound for a language neutral application. Please see the previous issues raised when they were in the list, which were obviously chosen to be unresolvable, hence the need for a specific well architectured solution. >> B.2.1 URLRequest interface > > This interface appears to be a more complicated version of the widely- > implemented XMLHttpRequest interface. I have written a specification > for XMLHttpRequest that the SVG working group is welcome to refer to > or copy verbatim into a generic specification for scripted HTTP: > > http://whatwg.org/specs/web-apps/current-work/#scripted This isn't even an accurate representation of the existing behaviour amoung the various implementations, it is also inappropriate for use in anything but ecmascript (or other scripting languages) Not using Events etc. > In HTML, Microsoft's dominance in the HTML browsing market has made > Microsoft's XMLHttpRequest interface (which was released well before > DOM3 Load and Save) quite popular (it's even used by large sites like > GMail). You're confusing popularity with it's the only option we've got. It's not a neat solution, especially as it not being specified anywhere we have 4 non-interopable implementations, we have to rely on a common subset, and in the case of Opera that subset is tiny. > In > SVG, however, there is no such huge demand for a specific interface, There is actually, there's the huge demand for the ASV interfaces which arrived not too much different time from XMLHttpRequest, they suffer from all the same problems though (other than interopability, where these simpler methods interoperate well) > Note that implementing URIRequest on top of an XMLHttpRequest > implementation would be non-trivial, requiring as much code as the > original XMLHttpRequest implementation itself, because the two > interfaces do not map well from one to the other (there are numerous > subtle differences, such as the values for readyState, and what each > method should return in each state). Maybe you could provide some more reasons to explain this as to me, (ignoring things like addContentFromFile, which is impossible in all but IE's implementation) it's not that many lines of ECMAScript that can map between the two. Jim.
Received on Sunday, 31 October 2004 11:57:51 UTC