Re: IDL: special DOMString that converts to Unicode

On Mon, 29 Oct 2012 17:57:01 +0200, Brendan Eich <brendan@mozilla.org>  
wrote:

>> I listed the APIs this affects. They are indeed mostly when things hit
>> the wire such as URLs and networking.
>
> Sorry I missed it -- but is it "quite a number" of APIs? That's still in  
> tension with "only" in Simon's reply.

I don't see how it's useful to discuss the wording here. Anne listed the  
APIs that use this today. I pointed out that we don't want APIs that don't  
need this to accidentally use it.

> Does the Unicode correctness requirement in implementations of these  
> APIs really require a new type in WebIDL, though?

We could continue doing what we do now, or we could do what Anne proposed,  
or we could do something else like having centralized rules defined  
*somewhere* that specs can hook into.

> Adding a new type makes mischief:
>
> * It may be used elsewhere than for interfaces to implementations that  
> need to check for valid Unicode encoding. s/may/will/ there, Murphy says.

(This is the same as the concern I raised with calling it "string".)

> * It puts the burden on the JS engine via WebIDL bindings, rather than  
> on the implementation.

I'm not convinced this is really the case -- the requirements in specs can  
usually be satisfied in any manner so long as the end result is equivalent  
to that of the spec. That said, it might make more sense to specify things  
that are closer to how they get implemented.

> Is this desirable? It might very well be better for the implementations  
> to do the checking, to avoid two passes over strings.
>
> * It mixes contingent implementation details into interface. Are the  
> interfaces you listed really concrete implementation APIs, or might they  
> be used (in the future if not now) for implementations that do not need  
> to sanitize?

I'm not sure I follow this point. Can you give an example of such a case,  
hypothetical or real?

cheers
-- 
Simon Pieters
Opera Software

Received on Monday, 29 October 2012 17:08:18 UTC