Re: Coordination
On Apr 15, 2013, at 6:00 AM, Arthur Barstow wrote: On 4/15/13 5:02 AM, ext Robin Berjon wrote: Note that next week there's a four-day meeting in San Jose involving HTML, WebApps, WebAppSec, and Web Crypto (at least). It's a bit short notice, but maybe we can experiment that there? I suspect it is too late to add new participants for WebApps' April 25-26 meeting but I can check if there is interest (logistics http://www.w3.org/wiki/Webapps/April2013Meeting). Earlier today I added WebApps -TC39 coordination as an agenda topic http://www.w3.org/wiki/Webapps/April2013Meeting#Potential_Topics. We should be able to accommodate remote voice calls and we will use W3C's #webapps channel. Personally, I'm in Europe speaking at a conference next week. However, I'll circulate this note to the TC39 members mailing list to see who might be available. Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Coordination
On Apr 15, 2013, at 2:02 AM, Robin Berjon wrote: I heartily agree with the sentiment in these three proposals, but I'm not sure that they're the best approach. To begin with, I can't formally speak on behalf of all the API-making groups but I would be very surprised if they weren't enthusiastic at the prospect of hosting a session dedicated to TC39 discussion. I think that you can consider yourselves permanently invited. The reason I bring this up, is that TC39 didn't go away with a lot of warm and fuzzies the only time we co-located a TC39 meeting with a TPAC (I believe it was 2009). It just wasn't clear where we fit in and how to engage with various W3C groups. Some of this is no doubt simply a matter of cultural and process differences but the end result was that TC39, as a group, didn't seem to really have a place there and within TC39 there hasn't been much interest in trying this again. So I think a standing invitation probably isn't enough. There really needs to be some proactive out-reach coming from the perspective that ECMAScript is one of the major cross-cutting web platform technologies and hence TC39 to be a real partner various W3C working groups. The parts I'm not sure about are about having a TPAC session and coordinating with the TAG. There aren't really any properly plenary sessions at TPAC anymore (at least there haven't been in the past two years), so this may not be optimal. We could reserve a dedicated Talk with TC39 breakout session every year. I don't know if that's enough, but it could be a start. I see. The only time I attended a TPAC it still had plenary sessions. So how does the W3C generally communicate plans, priorities, information, etc. that cross-cut various working groups? In general though, I think that holding such a session would be more efficient as part of the meeting of one of the larger API groups, typically WebApps. Things that get communicated to WebApps and decided there are likely to make their way to other groups relatively quickly. And I believe that might be more efficient than talking to the TAG. Even though things might change now that the TAG's make-up has evolved, I would expect API-making groups to listen to WebApps more readily than they'd listen to the TAG. I'll take your word for it as I don't really understand the working culture of W3C groups. My TAG suggestion comes form a longer term planning perspective. In TC39 we are already working on some aspects of ECMAScript 7 even though ECMAScript 6 won't be a standard until Dec. 2014. Are the things we are planning the things that W3C groups are likely to need at the end of this decade? We have our opinions, but it would seem some coordination with long term W3C planning would be appropriate. So to reformulate your three proposals: 1) At every TPAC there should be a presentation by TC39 to the W3C community, either in a dedicated breakout session or to WebApps. 2) W3C proactively invites participation from TC39 members in TPAC (we can handle the details offline). 3) WebApps has a second meeting (not at TPAC) every year, and it would be a good idea to catch up there as well. I can't unilaterally speak for TC39, but these sound like good first steps to me. Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Coordination (was: ES6 Modules)
On Sat, Apr 13, 2013 at 4:52 PM, Kevin Smith zenpars...@gmail.com wrote: Put concretely: if Futures are provided via libraries, but you can't assume (require) libraries, then you can't design DOM APIs around Futures. Clearly, one way to solve this is put Futures into the language, but another is to solve the extensibility problem so you can start requiring libraries. I don't understand this. Surely you wouldn't design a *platform API* to be dependent on userland JS libraries. No? I think I've taken us off into the weeds, and I apologize. What I was trying to say is that library authors have an advantage over platform authors, in that they can require other libraries. If the platform itself provides a mechanism for using and acquiring libraries (modules), then hopefully it'll be easier to move to better-designed APIs (or even multiple different APIs) without having to go back to TC39 for everything. Of course, you will still have the problems of defining core or standard libraries and ensuring their quality. -- Dirk ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Coordination (was: ES6 Modules)
I think I've taken us off into the weeds, and I apologize. What I was
trying to say is that library authors have an advantage over platform
authors, in that they can require other libraries.
No - this is good input. You want to be able to modularize your platform
API, and not have to hang everything off of window. This is a use case
that ES modules need to address.
{ Kevin }
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Coordination
Le 12/04/2013 14:10, Alex Russell a écrit : From the DOM side, I don't know that there's enough F2F contact to say that DOM authors need to be aware of X from the TC39 side will ever fly without some big checkbox in their lifecycle that says has been reviewed for idomatic API practice [yes|no]. This assumes that APIs come to life at the W3C and that when the first draft appears on the W3C side, there is still time to gather feedback and modify the API. This is true for some APIs, false for others. Every major vendor has recent examples of unilateral initiatives that were first implemented in a web browser then brought to the W3C. I see setImmediate for Microsoft, a bunch of FirefoxOS WebAPIs for Mozilla, Audio/File APIs on the Chrome side, etc. Rick Waldron wrote: As far as outreach, in my own experience whenever I've offered feedback directly to DOM API authors, I'm frequently met with responses such as that's not consistent with the platform [/end]. I've also sent my share of API feedback and been met with sometimes no responses at all which I personally interpreted as it's shipped or close enough to; it's too late to make an API change now. Of course, that's my interpretation :-) If we want a useful API idiomacy review process, this process has to start at a time it's still possible to change the API. One solution is for all vendors to submit an API to the W3C (or at least public-script-coord) *before* shipping it. I'm doubtful this will ever happen, but I'd be happy to read if major browsers representative said here that they're committed to never ship before the API has been reviewed for idiomacy. Another solution requires the review to happen internally within the organization implementing an API, that is a group [1] would discuss with the different vendors at times they're drafting an API. My main point here is that APIs being idiomatic will require more than just coordination between TC39 and the W3C. It will require an effort from implementors to share the APIs they're drafting before they ship it/bring it to standardisation. Also note that if a review process happens in the context of a unilateral initiative, what to do of the outcome of the review is up to the unilateral actor. David [1] I don't like the idea of this review process to be restricted to TC39 as being part of it is pay-to-play. Web devs have relevant feedback to share regarding JS APIs (duh!) and not necessarily the money to . Due to their fantastic API work, I wish the Node.js folks would also participate to this discussion. Unfortunate some vocal folks in the Node.js community have shown so much aversion towards standard bodies :-/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Coordination
On Sat, Apr 13, 2013 at 11:35 AM, David Bruant bruan...@gmail.com wrote: I've also sent my share of API feedback and been met with sometimes no responses at all which I personally interpreted as it's shipped or close enough to; it's too late to make an API change now. Of course, that's my interpretation :-) Whenever that happens feel free to bug me about it. If a WG does not response to feedback they are violating the W3C Process and it's pretty trivial to escalate that. I'm happy to help out. WGs are required to address feedback and reply to it. Furthermore, if you disagree with their response you can raise a Formal Objection which will make it even harder for them. I try not to resort to http://www.w3.org/Consortium/Process/ much, but if a WG is a pain it can definitely help. (As you point out though, sites rely on it is a pretty strong argument. The constraints there are not different from TC39.) If we want a useful API idiomacy review process, this process has to start at a time it's still possible to change the API. One solution is for all vendors to submit an API to the W3C (or at least public-script-coord) *before* shipping it. I'm doubtful this will ever happen, but I'd be happy to read if major browsers representative said here that they're committed to never ship before the API has been reviewed for idiomacy. I'm certainly pushing for this at Mozilla. My impression thus far (I've only been here a couple of months) is that we have lacked resources for that with Firefox OS and were under severe time constraints. We are committed though to implementing the APIs that come out of the standardization process too and we'll do our best to migrate everyone towards those. -- http://annevankesteren.nl/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Coordination
Anne van Kesteren wrote: If we want a useful API idiomacy review process, this process has to start at a time it's still possible to change the API. One solution is for all vendors to submit an API to the W3C (or at least public-script-coord) *before* shipping it. I'm doubtful this will ever happen, but I'd be happy to read if major browsers representative said here that they're committed to never ship before the API has been reviewed for idiomacy. I'm certainly pushing for this at Mozilla. My impression thus far (I've only been here a couple of months) is that we have lacked resources for that with Firefox OS and were under severe time constraints. Anney: we *did* submit drafts for all APIs needed for Firefox OS. See the lists compiled at http://brendaneich.com/2012/02/mobile-web-api-evolution/ (2012, based on work starting in fall 2011 well before anything shipped) and https://brendaneich.com/2013/03/mwc-2013-firefox-os-and-more-web-api-evolution/ (2013, and we still haven't shipped yet note well) Were you unaware of this, or did you have in mind other APIs we shipped that didn't have drafts in progress? There may have been a few around telephony, this was the proximate cause of the SysApps WG being chartered, but on the up side these APIs really are only for the dialer or a few other system apps, and neither needed nor wanted by other apps. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Coordination
Brendan Eich wrote: Anney (Sorry for the typo!) ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Coordination (was: ES6 Modules)
On Fri, Apr 12, 2013 at 9:49 PM, Rick Waldron waldron.r...@gmail.comwrote: On Fri, Apr 12, 2013 at 10:17 PM, Dirk Pranke dpra...@chromium.orgwrote: On Fri, Apr 12, 2013 at 8:06 AM, Anne van Kesteren ann...@annevk.nlwrote: On Fri, Apr 12, 2013 at 3:39 PM, Rick Waldron waldron.r...@gmail.com wrote: The DOM side should all be subscribed to es-discuss and read it on a regular basis. Additionally, our f2f meeting notes are a great way for them to keep up to date, as well as providing a good jump off for questions and concerns. Given the number of people working on platform APIs that should seems ever less likely to become a reality. We need a different strategy. I also think you need a different strategy. If people interested in defining new APIs for the web have to be tracking how the JS language itself is evolving, this is a total failure of both one or both sides. This statement negates itself—people defining new APIs have an obligation to understand the language in which the APIs they are writing will be used. Of course you have to understand the language, but you shouldn't have to be tracking the nuances of the implementation of proxies and private symbols in order to write a decent JS API. A slightly more ridiculous example to prove my point would be to suggest that web spec authors should also be tracking the minutes of WG21 (the ISO C++ committee), since all of these APIs are actually being implemented in C++ : However, I grant that there are three valid points between where we are and where we want to be: 1) A great many existing DOM APIs are very un-JS-friendly Agreed. 2) We need better examples of what JS-friendly APIs are (or should be) I can't believe I'm reading this, as if you believe there are no examples of real world code that is very JS-friendly? I'm sorry, I didn't write this at all clearly. There are lots of good JS APIs, of course, but very few of them are baked into browsers or part of the W3C's specs. Robin's Web API Design Cookbook is closer to what I had in mind. As far as outreach, in my own experience whenever I've offered feedback directly to DOM API authors, I'm frequently met with responses such as that's not consistent with the platform [/end]. 3) TC39 et al. need to give us a language where we can build sane DOM APIs without feeling like we need to change the language to do so :). Meanwhile, library authors have no trouble designing sane DOM APIs that web developers enjoy using. The difference: library authors listen to their users, DOM API authors do not. Right. This is close to what I was trying to say. TC39 (or at least the browser-based implementors who belong to it) has failed thus far to give us an environment where it's possible to use libraries trivially and with near-zero cost, so it's harder to take the stance that problems should be solved in libraries than it should be. The DOM API authors, on the other hand, have failed in exactly the way you describe. I am optimistic however we might soon be fixing both of these issues. To that end, we probably do need more *short-term* interaction, but I don't think asking everyone working on a DOM spec to follow es-discuss is the best way to do so. There's actually very little overlap between what is talked about most of the time on es-discuss and the sort of stuff a DOM spec author cares about. So far today, every response from a non-TC39 member has been to the tune of I want something, but I don't want to work for it, so find another way to give it to me, but I don't have any suggestions. There is no free lunch. If you want to know what's going on, here's the subscription page: https://mail.mozilla.org/listinfo/es-discuss I am trying to offer suggestions, and I've been subscribed to es-discuss for years :) I don't think TC39 is doing a bad job these days, and I think the types of discussions that go on on es-discuss are good and important, but I don't think they're the types of discussions that most API and library designers are interested in. Are you suggesting that we should have more language-user-oriented (as opposed to language-lawyer-oriented) discussions on es-discuss? -- Dirk ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Coordination
On Sat, Apr 13, 2013 at 7:14 PM, Brendan Eich bren...@mozilla.com wrote: Anney: we *did* submit drafts for all APIs needed for Firefox OS. See the lists compiled at http://brendaneich.com/2012/02/mobile-web-api-evolution/ (2012, based on work starting in fall 2011 well before anything shipped) and https://brendaneich.com/2013/03/mwc-2013-firefox-os-and-more-web-api-evolution/ (2013, and we still haven't shipped yet note well) Were you unaware of this, or did you have in mind other APIs we shipped that didn't have drafts in progress? There may have been a few around telephony, this was the proximate cause of the SysApps WG being chartered, but on the up side these APIs really are only for the dialer or a few other system apps, and neither needed nor wanted by other apps. Apologies for the ambiguity. I meant pushing for an API idiomacy review process. -- http://annevankesteren.nl/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Coordination
Anne van Kesteren wrote: Apologies for the ambiguity. I meant pushing for an API idiomacy review process. Thanks -- on that front, recent API work (DAP, WebApps, SysApps) has been about par for the course, from what I've seen. In other words, a mixed bag ranging from nicely-idiomatic or good-enough, all the way to we're-sorry-and-we-will-do-better-next-time ;-). And since nothing has progressed beyond LC yet AFAIK, there may still be time to fix things. But as I wrote privately, I don't think we can firehose all the new APIs through public-script-coord and get good API review results. We could go API by API in a more focused forum or meeting-like setting, with public-script-coord hosting the notices for upcoming reviews, progress updates, and review conclusions. Thoughts? /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Coordination (was: ES6 Modules)
On Sat, Apr 13, 2013 at 3:12 PM, Dirk Pranke dpra...@chromium.org wrote: As far as outreach, in my own experience whenever I've offered feedback directly to DOM API authors, I'm frequently met with responses such as that's not consistent with the platform [/end]. 3) TC39 et al. need to give us a language where we can build sane DOM APIs without feeling like we need to change the language to do so :). Meanwhile, library authors have no trouble designing sane DOM APIs that web developers enjoy using. The difference: library authors listen to their users, DOM API authors do not. Right. This is close to what I was trying to say. TC39 (or at least the browser-based implementors who belong to it) has failed thus far to give us an environment where it's possible to use libraries trivially and with near-zero cost, so it's harder to take the stance that problems should be solved in libraries than it should be. I don't understand what you're saying here. Is it just that JS doesn't have a module system yet? What else has TC39 failed to provide? Also, by definition, there's nothing available to library authors that isn't available to platform API authors. So I don't see how this is a reason for the current designs of DOM APIs. Sam ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Coordination (was: ES6 Modules)
On Sat, Apr 13, 2013 at 8:52 PM, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote: I don't understand what you're saying here. Is it just that JS doesn't have a module system yet? What else has TC39 failed to provide? Also, by definition, there's nothing available to library authors that isn't available to platform API authors. So I don't see how this is a reason for the current designs of DOM APIs. It would help if this was made a bit more concrete. I hope we all realize most of http://dom.spec.whatwg.org/ is over a decade old and cannot really be changed. The new things added to it are in much better shape. -- http://annevankesteren.nl/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Coordination (was: ES6 Modules)
On Sat, Apr 13, 2013 at 12:52 PM, Sam Tobin-Hochstadt sa...@ccs.neu.eduwrote: On Sat, Apr 13, 2013 at 3:12 PM, Dirk Pranke dpra...@chromium.org wrote: As far as outreach, in my own experience whenever I've offered feedback directly to DOM API authors, I'm frequently met with responses such as that's not consistent with the platform [/end]. 3) TC39 et al. need to give us a language where we can build sane DOM APIs without feeling like we need to change the language to do so :). Meanwhile, library authors have no trouble designing sane DOM APIs that web developers enjoy using. The difference: library authors listen to their users, DOM API authors do not. Right. This is close to what I was trying to say. TC39 (or at least the browser-based implementors who belong to it) has failed thus far to give us an environment where it's possible to use libraries trivially and with near-zero cost, so it's harder to take the stance that problems should be solved in libraries than it should be. I don't understand what you're saying here. Is it just that JS doesn't have a module system yet? What else has TC39 failed to provide? modules plus some mechanism for discovery and installation (for some definitions of those terms); equivalents to CPAN/PYPI/NPM/etc. Also, by definition, there's nothing available to library authors that isn't available to platform API authors. So I don't see how this is a reason for the current designs of DOM APIs. If you can assume a library, you can assume the existence of the library's abstractions. If it is difficult to assume (require) libraries, then your hands are tied when designing new standalone APIs. This is a problem C has always had, for example, as compared to Java, Perl, Python, etc. Put concretely: if Futures are provided via libraries, but you can't assume (require) libraries, then you can't design DOM APIs around Futures. Clearly, one way to solve this is put Futures into the language, but another is to solve the extensibility problem so you can start requiring libraries. -- Dirk ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Coordination
But as I wrote privately, I don't think we can firehose all the new APIs through public-script-coord and get good API review results. We could go API by API in a more focused forum or meeting-like setting, with public-script-coord hosting the notices for upcoming reviews, progress updates, and review conclusions. Thoughts? In principle, github would offer the means for review input from the public (those who are meant to be using those APIs later on). It might be too firehosey (everybody on the web submitting tiny yet mutually exclusive suggestions), but perhaps a protocol of serious reviews only, quality before quantity, please could be established? Or a filter by proven-to-be-useful contributions? Claus PS. I would permit public-script-coord to archive my messages, but I refuse to support an archive that doesn't even try to obfuscate email addresses. Hence they won't appear there:-( ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Coordination
On Sat, Apr 13, 2013 at 12:41 PM, Anne van Kesteren ann...@annevk.nl wrote: Apologies for the ambiguity. I meant pushing for an API idiomacy review process. I've just asked for the same in Blink: https://groups.google.com/a/chromium.org/forum/?fromgroups=#!topic/blink-dev/UYFU8uCTIZs. (I'll definitely be manually reviewing anything we get an Intent to Implement statement about.) ~TJ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Coordination (was: ES6 Modules)
Put concretely: if Futures are provided via libraries, but you can't
assume (require) libraries, then you can't design DOM APIs around Futures.
Clearly, one way to solve this is put Futures into the language, but
another is to solve the extensibility problem so you can start requiring
libraries.
I don't understand this. Surely you wouldn't design a *platform API* to be
dependent on userland JS libraries. No?
{ Kevin }
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Coordination (was: ES6 Modules)
On Thu, Apr 11, 2013 at 1:51 PM, Robin Berjon ro...@w3.org wrote: On 09/04/2013 16:51 , Brendan Eich wrote: First, this cuts both ways. Do you really want to get into the times even in the modern era, even in the last three years, when a W3C/WHATWG (the two are diverging again) piece of spec-work was done without consulting with es-discuss or any such group, resulting in a less than ideal JS API? I am not going to throw that stone, it's not my point. I'm asking you to refrain as well. It most certainly cuts both ways. What I'd be interested in though is if there's anything we can do to make it not cut at all. You mention reviewing JS APIs; we're working on quite a few of those — and we really want all the feedback we can get. Is there a simple, lightweight process that would ensure everyone's aware of ongoing work? From the DOM side, I don't know that there's enough F2F contact to say that DOM authors need to be aware of X from the TC39 side will ever fly without some big checkbox in their lifecycle that says has been reviewed for idomatic API practice [yes|no]. From the TC39 side, it wouldn't be hard to have a quick breifing at the front of every-other meeting to bring people up to date on the specs that are going through the process, need eyes, etc. No review in the meeting, but just a heads up that now's the time to weigh in on X, Y, and Z. Thoughts? I am loath to head towards something formal, but at our end we can certainly agitate for an informal rule like Whenever you produce a new API, or a major redesign, you must ping public-script-coord. I don't have a set idea as to how to improve this; suggestions are very welcome. My point is: if you want to review APIs, we're more than happy to facilitate that. Second, there is a list, public-script-co...@w3.org, cc'ed here, where this thread started, and which has existed all along, precisely to improve let's say DOM/JS coordination and API quality. We've used it from the es-discuss side. If it should have been used for something to do with modules, there's still time. We could definitely use increased awareness of what you're working on. I think a lot of people on this side are still under the impression that TC39 disappeared down a hole to work on ES4 and never came out. I'm not saying that it's justified, just that it's the sort of perception that we ought to dispel. Judging from the first reactions we're getting with Futures (mostly involving people staring like rabbits about to splat) we already need to do some outreach on this side, but it would certainly be helpful to get the occasional heads up for features that will definitely have a strong impact on API design and the platform in general. Modules are *definitely* a candidate for that treatment. -- Robin Berjon - http://berjon.com/ - @robinberjon ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Coordination (was: ES6 Modules)
On Fri, Apr 12, 2013 at 8:10 AM, Alex Russell slightly...@google.comwrote: On Thu, Apr 11, 2013 at 1:51 PM, Robin Berjon ro...@w3.org wrote: On 09/04/2013 16:51 , Brendan Eich wrote: First, this cuts both ways. Do you really want to get into the times even in the modern era, even in the last three years, when a W3C/WHATWG (the two are diverging again) piece of spec-work was done without consulting with es-discuss or any such group, resulting in a less than ideal JS API? I am not going to throw that stone, it's not my point. I'm asking you to refrain as well. It most certainly cuts both ways. What I'd be interested in though is if there's anything we can do to make it not cut at all. You mention reviewing JS APIs; we're working on quite a few of those — and we really want all the feedback we can get. Is there a simple, lightweight process that would ensure everyone's aware of ongoing work? From the DOM side, I don't know that there's enough F2F contact to say that DOM authors need to be aware of X from the TC39 side will ever fly without some big checkbox in their lifecycle that says has been reviewed for idomatic API practice [yes|no]. From the TC39 side, it wouldn't be hard to have a quick breifing at the front of every-other meeting to bring people up to date on the specs that are going through the process, need eyes, etc. No review in the meeting, but just a heads up that now's the time to weigh in on X, Y, and Z. The DOM side should all be subscribed to es-discuss and read it on a regular basis. Additionally, our f2f meeting notes are a great way for them to keep up to date, as well as providing a good jump off for questions and concerns. Rick ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Coordination (was: ES6 Modules)
On Friday, April 12, 2013, Rick Waldron wrote:
On Fri, Apr 12, 2013 at 8:10 AM, Alex Russell
slightly...@google.comjavascript:_e({}, 'cvml', 'slightly...@google.com');
wrote:
On Thu, Apr 11, 2013 at 1:51 PM, Robin Berjon
ro...@w3.orgjavascript:_e({}, 'cvml', 'ro...@w3.org');
wrote:
On 09/04/2013 16:51 , Brendan Eich wrote:
First, this cuts both ways. Do you really want to get into the times
even in the modern era, even in the last three years, when a W3C/WHATWG
(the two are diverging again) piece of spec-work was done without
consulting with es-discuss or any such group, resulting in a less than
ideal JS API? I am not going to throw that stone, it's not my point. I'm
asking you to refrain as well.
It most certainly cuts both ways. What I'd be interested in though is if
there's anything we can do to make it not cut at all.
You mention reviewing JS APIs; we're working on quite a few of those —
and we really want all the feedback we can get.
Is there a simple, lightweight process that would ensure everyone's
aware of ongoing work?
From the DOM side, I don't know that there's enough F2F contact to say
that DOM authors need to be aware of X from the TC39 side will ever fly
without some big checkbox in their lifecycle that says has been reviewed
for idomatic API practice [yes|no].
From the TC39 side, it wouldn't be hard to have a quick breifing at the
front of every-other meeting to bring people up to date on the specs that
are going through the process, need eyes, etc. No review in the meeting,
but just a heads up that now's the time to weigh in on X, Y, and Z.
The DOM side should all be subscribed to es-discuss and read it on a
regular basis.
I think that's totally fair and something the W3C needs to get people to do
more reflexively than is done today. Indeed, I'd be shocked if most of the
folks who are designing DOM APIs are subscribed today.
Additionally, our f2f meeting notes are a great way for them to keep up to
date, as well as providing a good jump off for questions and concerns.
Rick
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Coordination (was: ES6 Modules)
On Fri, Apr 12, 2013 at 3:39 PM, Rick Waldron waldron.r...@gmail.com wrote: The DOM side should all be subscribed to es-discuss and read it on a regular basis. Additionally, our f2f meeting notes are a great way for them to keep up to date, as well as providing a good jump off for questions and concerns. Given the number of people working on platform APIs that should seems ever less likely to become a reality. We need a different strategy. -- http://annevankesteren.nl/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Coordination (was: ES6 Modules)
On Apr 12, 2013 11:06 AM, Anne van Kesteren ann...@annevk.nl wrote: On Fri, Apr 12, 2013 at 3:39 PM, Rick Waldron waldron.r...@gmail.com wrote: The DOM side should all be subscribed to es-discuss and read it on a regular basis. Additionally, our f2f meeting notes are a great way for them to keep up to date, as well as providing a good jump off for questions and concerns. Given the number of people working on platform APIs that should seems ever less likely to become a reality. We need a different strategy. Feels like some tc39 member(s) should be invited experts to anything @w3c dealing with scripted apis as a checkpoint and that w3c folks should at least follow es-summary and review f2f notes. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Coordination
On Fri, Apr 12, 2013 at 4:15 PM, Brendan Eich bren...@secure.meer.net wrote: We need a few people who can drink from a firehose on all the lists, who then bubble issues up to public-script-coord. I wish I could. The problem is 1) there's many drafts http://www.w3.org/TR/#tr_Javascript_APIs (not complete), 2) many different lists because the W3C likes to operate that way and 3) the people developing the API don't always care about the API as much as just getting this new platform bit exposed and then move on. There's no sense of shared responsibility. I don't see an immediate way of making that better. Some of us are looking into A) just going through the specifications and giving concrete actionable feedback, B) figuring out what high-level advice to give, C) IDL that more strongly encourages idiomatic JavaScript. Another problem we have I think (related to 3 above) is that we don't have sufficient primitives so everyone ends up inventing their own variant. We have futures now, but we don't really have streams, the event API is due for an upgrade, the event loop should probably be exposed to script in some fashion. And resources to work on that kind of overhaul are scarce. -- http://annevankesteren.nl/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Coordination (was: ES6 Modules)
The DOM side should all be subscribed to es-discuss and read it on a regular basis. Additionally, our f2f meeting notes are a great way for them to keep up to date, as well as providing a good jump off for questions and concerns. Given the number of people working on platform APIs that should seems ever less likely to become a reality. We need a different strategy. Parts of the DOM side have weekly summaries, eg http://www.w3.org/QA/2013/03/openweb-weekly-2013-03-24.html Having such weeklies for all relevant spec groups, including TC39, with specific feeds (not just part of general news feeds) and then a feed aggregator on top (only for the various weeklies), might help giving interested parties an idea of when to dive in where. It might also establish a lower barrier on what everyone might be expected to follow? https://twitter.com/esdiscuss almost fits into that gap, but twitter isn't quite the right format, and suitable editing labeling are needed to guide readers to the right firehose at the right time. Claus ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Coordination (was: ES6 Modules)
Hi Anne, while I mostly agree with Rick, I also see the scalability problem you're worried about here. Part of the problem is that so many w3c platform APIs are designed without any appreciation of JavaScript esthetics, often it seems without any real JavaScript experience, and with WebIDL as the design language for working out and discussing these API designs. Due to heroic efforts by Cameron, WebIDL is now a workable formalism for specifying such APIs. But as a design language for discussing and working out the designs, WebIDL systematically leads to APIs hostile to the working JavaScript programmer. If more of the w3c's design discussions were phrased in terms of JavaScript APIs as they would appear in JS, that would help. Once a design is settled, then re-expressing it in WebIDL probably remains a necessary evil, but one that would hurt less. On Fri, Apr 12, 2013 at 8:06 AM, Anne van Kesteren ann...@annevk.nl wrote: On Fri, Apr 12, 2013 at 3:39 PM, Rick Waldron waldron.r...@gmail.com wrote: The DOM side should all be subscribed to es-discuss and read it on a regular basis. Additionally, our f2f meeting notes are a great way for them to keep up to date, as well as providing a good jump off for questions and concerns. Given the number of people working on platform APIs that should seems ever less likely to become a reality. We need a different strategy. -- http://annevankesteren.nl/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Coordination
I'm really happy to see this thread. The past attempts to establish better communications and coordination between the W3C and Ecma/TC39 have had only limited success. I think one cause has been a lack of understanding of goals, plans, progress, and processes among the general population of participants in the two groups. I have a couple specific suggestions on how to improve this: 1) At every TPAC there should be an invited presentation by a representative of TC39 updating the W3C community on TC39/ECMAScript news, recent work, and future plans. 2) The W3C should proactively invite and encourage TC39 participants to attend and participate at TPACs as if they were active W3C participants. 3) At some regular interval (annually, bi-annually) there should be a formal joint meeting between the TAG and core TC39 members. This is arguably less important now that we have good cross-membership in the two groups but I think it is still be important to try to establish an official communcations path and shared vision at that level. I realize that this mailing list probably isn't the best one for submitting these suggestions, but this is where we having the conversation and I think the push for coordination improvements needs to start at the grass roots level. Thanks, Allen Wirfs-Brock Project Editor, Language Specification ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Coordination (was: ES6 Modules)
On Fri, Apr 12, 2013 at 8:06 AM, Anne van Kesteren ann...@annevk.nl wrote: On Fri, Apr 12, 2013 at 3:39 PM, Rick Waldron waldron.r...@gmail.com wrote: The DOM side should all be subscribed to es-discuss and read it on a regular basis. Additionally, our f2f meeting notes are a great way for them to keep up to date, as well as providing a good jump off for questions and concerns. Given the number of people working on platform APIs that should seems ever less likely to become a reality. We need a different strategy. I also think you need a different strategy. If people interested in defining new APIs for the web have to be tracking how the JS language itself is evolving, this is a total failure of both one or both sides. A slightly more ridiculous example to prove my point would be to suggest that web spec authors should also be tracking the minutes of WG21 (the ISO C++ committee), since all of these APIs are actually being implemented in C++ : However, I grant that there are three valid points between where we are and where we want to be: 1) A great many existing DOM APIs are very un-JS-friendly 2) We need better examples of what JS-friendly APIs are (or should be) 3) TC39 et al. need to give us a language where we can build sane DOM APIs without feeling like we need to change the language to do so :). To that end, we probably do need more *short-term* interaction, but I don't think asking everyone working on a DOM spec to follow es-discuss is the best way to do so. There's actually very little overlap between what is talked about most of the time on es-discuss and the sort of stuff a DOM spec author cares about. -- Dirk ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Coordination (was: ES6 Modules)
On Fri, Apr 12, 2013 at 10:17 PM, Dirk Pranke dpra...@chromium.org wrote: On Fri, Apr 12, 2013 at 8:06 AM, Anne van Kesteren ann...@annevk.nlwrote: On Fri, Apr 12, 2013 at 3:39 PM, Rick Waldron waldron.r...@gmail.com wrote: The DOM side should all be subscribed to es-discuss and read it on a regular basis. Additionally, our f2f meeting notes are a great way for them to keep up to date, as well as providing a good jump off for questions and concerns. Given the number of people working on platform APIs that should seems ever less likely to become a reality. We need a different strategy. I also think you need a different strategy. If people interested in defining new APIs for the web have to be tracking how the JS language itself is evolving, this is a total failure of both one or both sides. This statement negates itself—people defining new APIs have an obligation to understand the language in which the APIs they are writing will be used. A slightly more ridiculous example to prove my point would be to suggest that web spec authors should also be tracking the minutes of WG21 (the ISO C++ committee), since all of these APIs are actually being implemented in C++ : However, I grant that there are three valid points between where we are and where we want to be: 1) A great many existing DOM APIs are very un-JS-friendly Agreed. 2) We need better examples of what JS-friendly APIs are (or should be) I can't believe I'm reading this, as if you believe there are no examples of real world code that is very JS-friendly? As far as outreach, in my own experience whenever I've offered feedback directly to DOM API authors, I'm frequently met with responses such as that's not consistent with the platform [/end]. 3) TC39 et al. need to give us a language where we can build sane DOM APIs without feeling like we need to change the language to do so :). Meanwhile, library authors have no trouble designing sane DOM APIs that web developers enjoy using. The difference: library authors listen to their users, DOM API authors do not. To that end, we probably do need more *short-term* interaction, but I don't think asking everyone working on a DOM spec to follow es-discuss is the best way to do so. There's actually very little overlap between what is talked about most of the time on es-discuss and the sort of stuff a DOM spec author cares about. So far today, every response from a non-TC39 member has been to the tune of I want something, but I don't want to work for it, so find another way to give it to me, but I don't have any suggestions. There is no free lunch. If you want to know what's going on, here's the subscription page: https://mail.mozilla.org/listinfo/es-discuss Rick -- Dirk ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
