Re: ByteString in Web IDL

On 7/10/13 12:35 AM, Norbert Lindenberg wrote:
> So there's a new fundamentally broken type in a specification that's the foundation for all Web APIs, just to make it easier to describe a few semi-broken legacy APIs elsewhere

To make it _possible_ to describe them, not to make it easier.

There's a lot of stuff in WebIDL that's there only or mostly to be able 
to describe legacy APIs.  named/indexed getters/setters, bytestring, 
some of the weirdness in how single-operation callback interfaces 
behave, legacycaller, [LenientThis], [ImplicitThis], [NamedConstructor], 
[TreatNonCallableAsNull], [TreatNullAs], [TreatUndefinedAs], and 
probably others that I missed.

I agree that it should be more clearly marked which parts are there for 
that reason, of course.

> and you hope that nobody else will use that new type?

Or that if they do, then it will be caught by whoever is 
reviewing/implementing that specification.  Again, more clearly marking 
ByteString as legacy-only would help.

> If XMLHttpRequest needs weird behavior for legacy reasons, then that should be explained in the XMLHttpRequest spec.

The XMLHttpRequest spec operates after the WebIDL binding has done 
whatever it does to the arguments.  At that point it's actually 
impossible to implement the ByteString behavior in a UA in which 
DOMString is UTF-8, for example, if the arguments were marked as 
DOMString in the IDL.

> Which was mostly wrong (but not uncommon) in the past, and is even wronger and unnecessary in the future.

Again, we're talking about documenting an existing API, not designing a 
new one.

> In method and header names?

In header names.  Servers obviously don't send method names.

-Boris

Received on Wednesday, 10 July 2013 04:45:47 UTC