Unsound ECMAScript objects - Was:Re: SVG 1.2 Comment: Detailed last call comments (all chapters)

"Ian Hickson" <ian@hixie.ch> wrote in message 

>> 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.


Received on Sunday, 31 October 2004 11:57:51 UTC