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
