Re: Help with WebIDL v1?

On 12/03/2014 11:10 AM, Boris Zbarsky wrote:
> On 12/3/14, 6:02 AM, Yves Lafon wrote:
>> Pretty much like refactoring XHR using Fetch or not. Most
>> implementations will most probably move to the latest version, but the
>> external interface will be the same.
>
> "External interface" being the IDL syntax in this case, not the
> resulting web-exposed interface, right?
>
>> In the case of Sequence, the ES
>> binding says in the two versions "IDL sequence<T> values are represented
>> by ECMAScript Array values."
>
> That's only really true for sequence return values in v2.  sequence
> arguments are represented by ES iterables.
>
>> The option 2 you outline seems best here, the syntax is considered as
>> stable (well, can be expanded, things can be declared obsolete, but
>> there won't be breaking changes), but implementations (as in the es
>> binding algorithms) may change to match the evolution of the underlying
>> language.
>
> OK.  I can live with this as long as the people referencing v1 can live
> with it.
>
>>> Or another example: in v1 having an indexed getter implies nothing
>>> about being iterable, but in v2 it implies ES6 iterability.
>>
>> This is an example of v1 plus one feature.
>
> Not plus an IDL feature.  As in, this is not a case of "v2 adds some IDL
> syntax compared to v1, but if you never use it in your spec you never
> have to worry about it".  This is a case of "the same syntax has
> different resulting behavior in implementations depending on which
> version of IDL they implement, leading to possible lack of interop for
> different implementations of your spec depending on which IDL version
> they choose to use".
>
> This is why in option 2 it's important to spell out what the actual
> requirements on implementations are that arise from the IDL reference.
>
>> Another option would be to define only the syntax and leave the bindings
>> to v2 only, but it wouldn't help much for testing.
>
> Indeed.  Or, again, actual interop.

Another way to phrase this question: what would the CR exit criteria be 
for such a WebIDL v1?  The reason why I bring this up is that if they 
are too low to be meaningful, that brings into the question whether or 
not this exercise is meaningful.  Similarly, if they are too high to be 
likely to be met.

If, on the other hand, there is a "sweet spot" some place in the middle; 
then perhaps this effort should proceed.

By analogy, the parsing of http: absolute URLs is solid and unlikely to 
change, but determining the origin of file: URLs isn't.  Clearly 
identifying what parts are widely deployed and unlikely to change vs 
those that aren't may be a path forward.

> -Boris

- Sam Ruby

Received on Wednesday, 3 December 2014 16:50:26 UTC