Allen.Wirfs-Brock at microsoft.com
Tue Jun 9 21:26:47 PDT 2009
It seems to me that the topics you mention here can easily fall within the character of ECMA TC39. Personally, I think it will be better for the community if all standards work related to ECMAScript is done within one umbrella organization rather than having multiple organizations trying to divide up the ECMAScript standards turfs. Ultimately, it's the same set of browser providers and often the same individuals that have to be involved with all of these activities so it's just more efficient if we do it in a single venue.
I agree that, a standards meeting is not the ideal place to do design work. No committee is. However, the way it really works is that most of the serious design work usually gets done by a few individual outside of the "committee" process and then the design proposals are presented to be reviewed and tweaked by the committee. That isn't much different from how real design occurs in any venue.
The one possible downside for some people may be the ECMA membership requirement. However, any organization that has any actual standing to serve as avenue for creating standards is going to have some sort of criteria for participation.
This mailing list is actually not an official ECMA list. Instead it is essentially an open communications zone that is frequented both by individuals who are actively involved in ECMA TC-39 and members of the community who are interested in the evolution of ECMAScript but are not ECMA members. I think it has been working pretty well in that regard. The topic you are interested could also be discussed on this list or if it becomes too confusing intermingling these topics with language design we could set up a parallel list for debugging related discussions.
Informally, this could get started simply by starting to have discussions on this list. To turn this work into an official TC39 activity the next step would probably be for the interested individuals who work for ECMA member companies (Google, Yahoo, Microsoft, Mozilla, Apple, Opera, etc.) to talk to their organizations' TC39 representatives. If you aren't affiliated with an ECMA member you might want to talk to the ECMA secretariat about what it takes to become a member. The next TC39 meeting is the last week of July in Redmond WA and this topic could easily be put on the agenda if there is member interest.
Thanks for bringing this up,
From: es-discuss-bounces at mozilla.org [mailto:es-discuss-bounces at mozilla.org] On Behalf Of Patrick Mueller
Sent: Tuesday, June 09, 2009 8:02 PM
Subject: debugging interfaces
Today on the serverjs mailing list, the subject of standardizing debugging interfaces came up.
As Mark notes in his post on the thread, something on the level of JPDA (JDI et al), or the more "modern" JVMTI (http://java.sun.com/javase/6/docs/technotes/guides/jvmti/) might be the sort of things to target, in terms of functionality.
I also noticed Charles McCaffieNevile mentioned standardized debugging API in a movie recently placed up on Yahoo Theatre (at about 14:50):
On a somewhat related note, there has been some work making the debugging experience better for developers, by making use of some non-standard conventions in source code. Two of these I'm familiar with are FireFox's "//@ sourceURL" annotation to 'name' eval() and Function() code blocks, and WebKit's displayName property to name otherwise anonymous functions. In both of these cases, the functionality is provided purely for the use of developer tooling - debugging and profiling. Links to more info on these here:
I've run into a few people interested in looking into this, but it's not quite clear to me where work relating to this should happen. I tend to view standards groups as not the places to do design work, so didn't really think ECMA would be the right place to talk about this, but Mark Miller indicated it would be good to at least post the thought up here.
So, question is, where might folks interesting in this stuff work on this? Here? I was also thinking the nascent Open Web Advocacy group might be another place:
Patrick Mueller - http://muellerware.org/
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss