Re: Unsound ECMAScript objects

"Ian Hickson" <ian@hixie.ch>

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

If that organisations members ever re-appear and start responding to 
questions on the list, I will of course continue to contribute, as I have 
done extensively in the past.  Equally with the WHAT-WG specification you 
cite specifically saying   "It is very wrong to cite this as anything other 
than a work in progress. Do not implement this in a production product. " 
It is not usable by another specification.

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

If they use DOM events, then they're not re-using existing implementations - 
and it's more confusing to have similarly named but different 
implementations than it is to have something with a completely new name.

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

They're not bugs, there's no specification, once there's a specification I 
can file bugs, that said I've filed bugs against two of the implementations 
already, in areas where they cause problems, unfortunately Opera do not 
encourage bug reporting by giving me any way to point to the ones raised 
there.

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

but as you've just acknowledged XMLHTTPRequest needs work, there's no fully 
existing interopable ones and you need to redefine things in terms of DOM 
events, breaking backwards compatibility anyway.  DOM 3 L+S isn't a solution 
in this as it doesn't meet the requirements to set http headers etc. and is 
tied to XML.

Jim.

Received on Sunday, 31 October 2004 20:14:04 UTC