Re: IDL: special DOMString that converts to Unicode

Anne van Kesteren wrote:
> On Mon, Oct 29, 2012 at 1:05 AM, Brendan Eich<brendan@mozilla.org>  wrote:
>> Where is the "overhead necessary", exactly? If it's all over the place,
>> we'll have a problem with developers and implementors, who won't want to
>> bottleneck on (re-)checking all the time.
>
> 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.

> We'd want a checked type to formalize (if possible) that the re-checking has
> been minimized for a given implementation.
>
> But why are we checking at all? JS allows naughty strings to be formed, but
> if there's a wire protocol that forbids them, then the API to speak that
> protocol should hide the detail of the implementation doing the checking.
> Push the checking out to the edge of the system where i/o happens.
>
> Yeah, this is about those APIs...

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

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.

* It puts the burden on the JS engine via WebIDL bindings, rather than 
on the implementation. 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?

/be

Received on Monday, 29 October 2012 15:57:41 UTC