W3C home > Mailing lists > Public > public-script-coord@w3.org > January to March 2013

Re: Standardizing console APIs: Where?

From: Allen Wirfs-Brock <allen@wirfs-brock.com>
Date: Tue, 26 Feb 2013 18:58:42 -0800
Cc: Brian Kardell <bkardell@gmail.com>, Jorge Chamorro <jorge@jorgechamorro.com>, Marcos Caceres <w3c@marcosc.com>, "public-script-coord@w3.org" <public-script-coord@w3.org>, Domenic Denicola <domenic@domenicdenicola.com>, "Hill, Clint" <clint.hill@goaaa.com>
Message-Id: <13E3A942-FC8F-476D-BC52-B56A0A14FD2D@wirfs-brock.com>
To: Mark S. Miller <erights@google.com>

On Feb 26, 2013, at 4:42 PM, Mark S. Miller wrote:

> On Tue, Feb 26, 2013 at 2:06 PM, Brian Kardell <bkardell@gmail.com> wrote:
> It seems that I may have mixed a few assumptions from side conversations on twitter/chat and been less clear than I could have been.
> 
> My question here was really a few fold:
> 
> 1. Does anyone else feel like we _should_ have a standard 
> 
> I feel strongly that console should be standardized.
> 
>  
> 2. Given that this goes beyond the browser, where should that standard live?  I feel like its proper home is ECMA since the API, again, has not really anything to do with browser necessarily.
> 
> I agree.
> 
>  
> 3. If ECMA, is it part of the language (ES7?) or is it separate like i18n?  I was actually suggesting that my opinion is the later, this feels like an ECMA module that could use standardization and is commonly imported in browsers and many engines for back-compat as 'console' (though I suggesting 'logging' is a better API term).  I also suggested (in the strawman) that it could start _very_ small with the abstract APIs that are at least universally non-breaking (even if they might do something slightly different) and have been fermented for years and years - thus it should mostly be an easy approval to find a home and basis on which to gather proposals and consensus   
> 
> Those are my merely opinions and rationale - I am happy to be wrong on any of them :)
> 
> Both could work. My first reaction is that it makes more sense to propose this for ES7, rather than create a separate track. But I don't have any strong basis for this. It does meet the same enabling criteria as i18n: It is largely orthogonal from the rest of ES7 and so need not be synchronized with it.

I think it will really come down to the availability of warm bodies who want to work on this.  Most of us who are active TC39 participants are already pretty fully consumed working on committed ES6 features. The I18N work was able to make rapid progress because it brought with it a new set of people who where ready and willing to devote time to it.  The same think could happen with console, but for it to happen quickly may require some new people from the current TC39 Ecma member organizations or new organizations that will join Ecma.  Any takers?


Allen
Received on Wednesday, 27 February 2013 02:59:13 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 May 2013 19:30:09 UTC