Fwd: Standardizing console APIs: Where?

[Brian Kardell]

Somehow this thread wound up forking only to public-script-coord at some
point - not sure where.  See comments from awb, alex russell, mark miller
and others:
http://lists.w3.org/Archives/Public/public-script-coord/2013JanMar/thread.html

-Brian

---------- Forwarded message ----------
From: Robin Berjon <robin at w3.org>
Date: Wed, Feb 27, 2013 at 5:35 AM
Subject: Re: Standardizing console APIs: Where?
To: Brian Kardell <bkardell at gmail.com>
Cc: "public-script-coord at w3.org" <public-script-coord at w3.org>


On 26/02/2013 23:06 , Brian Kardell wrote:

> 1. Does anyone else feel like we _should_ have a standard
>

I think that this thread has shown that there are interoperability issues.
Given that this is a debugging tool, you really want it to have predictable
behaviour so as not to waste time looking for a problem that in fact comes
from the console API.


 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 think that it makes more sense in ECMA, but if for whatever reason that
doesn't work out you're welcome to bring it to W3C.


 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
>

I don't have a specific opinion on how ECMA organises work, but I strongly
agree with the idea of starting very small and iterating, even if it means
that you release several version in a relatively short period of time.


-- 
Robin Berjon - http://berjon.com/ - @robinberjon



-- 
Brian Kardell :: @briankardell :: hitchjs.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130227/3b1450f1/attachment.html>