Re: Unsound ECMAScript objects

On Sun, 31 Oct 2004, Jim Ley wrote:
>>>
>>> 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.

While I agree that there are edge cases that are not well implemented, the 
basic functionality (which is all that would need to be specified) is 
definitely well understood and widely implemented.

It also seems quite possible to implement language-neutral versions of 
these methods. In particular, the variants taking Function objects as 
their first argument can just be defined in terms of taking interfaces 
much like EventListeners:

   http://whatwg.org/specs/web-apps/current-work/#timeouts

This can be grand-fathered for ECMAScript by saying that Function objects 
implement the relevant interface.

If you see any issues with the way these methods are defined above, please 
send them to whatwg@whatwg.org. (Assuming you want them fixed, anyway.)


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

Please raise the problems you have seen with whatwg@whatwg.org and I will 
endeavour to fix them. The interfaces above were derived from detailed 
testing of existing implementations, as well as close reading of the 
source files of implementations I had access to.


> it is also inappropriate for use in anything but ecmascript (or other 
> scripting languages). Not using Events etc.

I urge you to re-examine the definitions cited above, as they do use DOM 
events and should in fact be compatible with most languages.


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

WHATWG's specification notwithstanding, presumably.


> --we have 4 non-interopable implementations

Please let me know which areas you believe are non-interoperable, so that 
I may file bugs on the relevant implementations and get them fixed. I am 
aware of several differences between some implementations and the spec on 
the WHATWG site (such as Opera lacking support for custom HTTP headers and 
Mozilla not handling multiple HTTP headers by concatenating them) but I 
welcome further comments. It is in all our interests to fix the 
implementations to be interoperable.


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

Is this interface exactly URIRequest? If not, then apparently the working 
group does not consider compatibility with that subset to be important, 
and in that case using XMLHttpRequest or DOM3 Load and Save instead of 
reinventing a new API would seem to be a better solution.


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

It's not that many lines to implement XMLHttpRequest in the first place. 
The two interfaces have many subtle differences, each of which needs to be 
handled if URIRequest is to be implemented conformant to the 
specification. I have already given examples (such as the values for 
readyState, and what each method should return in each state).

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Sunday, 31 October 2004 19:42:05 UTC