Re: Help with WebIDL v1?
On Mon, 1 Dec 2014, Boris Zbarsky wrote: On 12/1/14, 1:49 PM, Travis Leithead wrote: I believe so; this will give many specs a baseline WebIDL document to point to in their references at the very least. Many specs don't rely on the more advanced feature set being defined in WebIDL Second Edition. Here's the problem. As of today, v2 is not just v1 plus some more features. They actually have some disagreements on how identical IDL syntactic constructs are handled. For example, sequence behavior is different: in v1 a sequence has magic for platform array objects and the gets the length property and goes from 0 to length, while in v2 a sequence is an iterable and uses the ES6 iterator protocol. 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. In the case of Sequence, the ES binding says in the two versions IDL sequenceT values are represented by ECMAScript Array values. 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. 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. More generally, v1 is pretty much defined in ES5 terms, while v2 is aiming for closer convergence with ES6. What happens when a spec uses a sequence argument and references v1? Are UAs supposed to implement the v1 behavior or v2 behavior? However, let's not hijack this thread; I'd love to hear what the next steps are for moving this v1 forward. I think that actually depends on how we want to handle the problem I describe above. Some obvious options are: 1) Backport all behavior changes from v2 to v1 so they agree on the set of syntactic constructs supported by v1. This makes v1 depend on ES6, which I understood to be a non-goal (or perhaps even anti-goal, given ES6 is not finalized yet? But it's close). 2) Treat v1 as a syntax spec (with v2 a superset of the syntax) and explicitly say somewhere in v1 that v2 can redefine the behavior. Not sure how happy people referencing v1 will be with that. Other options? Another option would be to define only the syntax and leave the bindings to v2 only, but it wouldn't help much for testing. -- Baroula que barouleras, au tiéu toujou t'entourneras. ~~Yves
Re: Help with WebIDL v1?
On Wed, Dec 3, 2014 at 3:02 PM, Yves Lafon yla...@w3.org wrote: Another option would be to define only the syntax and leave the bindings to v2 only, but it wouldn't help much for testing. Well we don't want to test something known to be wrong (e.g. sequence). And we want to retain the ability to make changes to the IDL syntax as we discover problems with it. -- https://annevankesteren.nl/
Re: Help with WebIDL v1?
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 sequenceT 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. -Boris
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 sequenceT 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
RE: Help with WebIDL v1?
From: Sam Ruby [mailto:ru...@intertwingly.net] 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. I think just having the syntax in v1 does not make progressing v1 a useful indeavor. My understanding of how V1 was being maintained up-to-date was that updates to the binding that were shared across common syntax in both v1 and v2 were being back-ported to v1 so that there were no inconsistencies in binding. In other words, if you were looking at v1, you'd see the latest algorithms and bindings, but for areas of v2 that were wholly new concepts, those would not exist in v1. Based on what Boris has said, I'm guessing that this practice has been discontinued :( I don't think we need to have a requirement of maintaining an ES5-level goal for v1. Large parts of ES6 are now shipping in various browsers, so we really have no reason to keep an ES5-based spec in development. Coming back to CR exit criteria, I think we need to hold v1 to the same standard we're holding v2, which means [at least] porting back the updated algorithms for handling sequences, named properties, indexed properties, etc. which have diverged. I suspect that there are still some shared areas of v2 and v1 that are not yet locked down yet, and we should focus our collective efforts on stabilizing those features before working on v2-only syntax features. If, on the other hand, there is a sweet spot some place in the middle; then perhaps this effort should proceed. I'm not sure what a middle-ground would look like--perhaps a less-strenuous test suite? E.g., HTML's passive-permissive testing approach? 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. And I think that v1 should be that slice of widely deployed and unlikely to change features. If that means pulling out sequence from v1, then perhaps that's another approach. I'm of the view that we should publish something soon to enable the stable reference for a variety of specs. Publishing is a process that helps focus and direct our efforts, and even if it's not perfect, it becomes a building block for future updates. We've let WebIDL just hang-out for too long now, and folks new to the area don't know what's more stable and what isn't. Again, publishing WebIDL is important to Microsoft, and we believe important to a lot of other customers. Consequently I'm ready to put pen to paper to make this happen if we can agree on a direction. Ideally, this effort doesn't distract too much from active work on v2. - Sam Ruby
Help with WebIDL v1?
Yves, At TPAC, I mentioned wanting to help move along WebIDL v1 to REC. Can you enumerate the next steps, and where I might be able to help? Thanks! -Travis
Re: Help with WebIDL v1?
On Mon, Dec 1, 2014 at 12:57 PM, Travis Leithead travis.leith...@microsoft.com wrote: At TPAC, I mentioned wanting to help move along WebIDL v1 to REC. Can you enumerate the next steps, and where I might be able to help? Thanks! Is there any actual value in doing this, since v2 has many additions, improvements, and bug fixes over the contents of v1? ~TJ
RE: Help with WebIDL v1?
I believe so; this will give many specs a baseline WebIDL document to point to in their references at the very least. Many specs don't rely on the more advanced feature set being defined in WebIDL Second Edition. However, let's not hijack this thread; I'd love to hear what the next steps are for moving this v1 forward. If there are bug fixes and improvements that need to go back to v1, than I'm volunteering to help get that work done. -Original Message- From: Tab Atkins Jr. [mailto:jackalm...@gmail.com] Sent: Monday, December 1, 2014 1:36 PM To: Travis Leithead Cc: Yves Lafon; Adrian Bateman; public-webapps Subject: Re: Help with WebIDL v1? On Mon, Dec 1, 2014 at 12:57 PM, Travis Leithead travis.leith...@microsoft.com wrote: At TPAC, I mentioned wanting to help move along WebIDL v1 to REC. Can you enumerate the next steps, and where I might be able to help? Thanks! Is there any actual value in doing this, since v2 has many additions, improvements, and bug fixes over the contents of v1? ~TJ
Re: Help with WebIDL v1?
On 12/1/14, 1:49 PM, Travis Leithead wrote: I believe so; this will give many specs a baseline WebIDL document to point to in their references at the very least. Many specs don't rely on the more advanced feature set being defined in WebIDL Second Edition. Here's the problem. As of today, v2 is not just v1 plus some more features. They actually have some disagreements on how identical IDL syntactic constructs are handled. For example, sequence behavior is different: in v1 a sequence has magic for platform array objects and the gets the length property and goes from 0 to length, while in v2 a sequence is an iterable and uses the ES6 iterator protocol. Or another example: in v1 having an indexed getter implies nothing about being iterable, but in v2 it implies ES6 iterability. More generally, v1 is pretty much defined in ES5 terms, while v2 is aiming for closer convergence with ES6. What happens when a spec uses a sequence argument and references v1? Are UAs supposed to implement the v1 behavior or v2 behavior? However, let's not hijack this thread; I'd love to hear what the next steps are for moving this v1 forward. I think that actually depends on how we want to handle the problem I describe above. Some obvious options are: 1) Backport all behavior changes from v2 to v1 so they agree on the set of syntactic constructs supported by v1. This makes v1 depend on ES6, which I understood to be a non-goal (or perhaps even anti-goal, given ES6 is not finalized yet? But it's close). 2) Treat v1 as a syntax spec (with v2 a superset of the syntax) and explicitly say somewhere in v1 that v2 can redefine the behavior. Not sure how happy people referencing v1 will be with that. Other options? -Boris
