gadgets.log prototype

[Evan Gilbert]

http://codereview.appspot.com/28059

Suggested spec changed from original proposal:
- Think it makes sense to model the API after the very popular Firebug/WebKit logging API. Instead of gadgets.log(msg, level), the proposed API is gadgets.log(msg), gadgets.warn(msg), and gadgets.error(msg), in addition to gadgets.setLogLevel(level)
- Added gadgets.log.NONE as a logging level, to suppress logging entirely.

Other notes:
- console.log() in Firebug supports a list of arguments which are formatted as a string. However, this isn't supported in WebKit flavors, and I thought it best to leave out of the core API. Think this can be an implementation choice (to accept a list of parameters instead of the one message param)
- Considered that we could just create the Firebug/WebKit console object if it doesn't exist on a browser - the API would then have been console.log() (which would always work). However, it was pointed out to me that the setLogLevel() function is important - you really don't want random Firebug messages in production. I could even set the logLevel as a URL parameter in different implementations (&debugLevel=3)
- The API is a little strange with namespaces. We have console.log both as a function and console.log as a namespace. I think this is better in the end - the API calls need to be short to be effective (so no gadgets.log.log()), and gadgets.log felt like the right namespace (I tried "gadgets.logging" in an early draft, but it just didn't stick), but I thought it worth mentioning.

A big note is that gadgets.log() is very useful. I started using this in internal development projects, and I can't live without it. Having a log() statement that is always available, without needing additional includes, is very helpful.

Evan

[Lane LiaBraaten]

On Tue, Mar 17, 2009 at 8:13 PM, Evan Gilbert <uid...@google.com> wrote:

http://codereview.appspot.com/28059

Suggested spec changed from original proposal:
- Think it makes sense to model the API after the very popular Firebug/WebKit logging API. Instead of gadgets.log(msg, level), the proposed API is gadgets.log(msg), gadgets.warn(msg), and gadgets.error(msg), in addition to gadgets.setLogLevel(level)
- Added gadgets.log.NONE as a logging level, to suppress logging entirely.

+1

[Arne Roomann-Kurrik]

On Tue, Mar 17, 2009 at 8:13 PM, Evan Gilbert <uid...@google.com> wrote:

http://codereview.appspot.com/28059

Suggested spec changed from original proposal:
- Think it makes sense to model the API after the very popular Firebug/WebKit logging API. Instead of gadgets.log(msg, level), the proposed API is gadgets.log(msg), gadgets.warn(msg), and gadgets.error(msg), in addition to gadgets.setLogLevel(level)
- Added gadgets.log.NONE as a logging level, to suppress logging entirely.

Other notes:
- console.log() in Firebug supports a list of arguments which are formatted as a string. However, this isn't supported in WebKit flavors, and I thought it best to leave out of the core API. Think this can be an implementation choice (to accept a list of parameters instead of the one message param)

We would want to be careful about this, as developers expecting multiple arguments to be logged on a system that didn't implement this would likely have most of their important logging information dropped (I typically use something like console.log("functionName", arg1, arg2); ).  I think we can just safely say that only one argument will be supported.
 

- Considered that we could just create the Firebug/WebKit console object if it doesn't exist on a browser - the API would then have been console.log() (which would always work). However, it was pointed out to me that the setLogLevel() function is important - you really don't want random Firebug messages in production. I could even set the logLevel as a URL parameter in different implementations (&debugLevel=3)
- The API is a little strange with namespaces. We have console.log both as a function and console.log as a namespace. I think this is better in the end - the API calls need to be short to be effective (so no gadgets.log.log()), and gadgets.log felt like the right namespace (I tried "gadgets.logging" in an early draft, but it just didn't stick), but I thought it worth mentioning.

A big note is that gadgets.log() is very useful. I started using this in internal development projects, and I can't live without it. Having a log() statement that is always available, without needing additional includes, is very helpful.

+1 !
 

Evan 

--
OpenSocial IRC - irc://irc.freenode.net/opensocial

[Scott Seely]

I think this makes sense.

 

Please create a patch.

[Evan Gilbert]

On Mon, Mar 30, 2009 at 11:52 AM, Arne Roomann-Kurrik <kur...@google.com> wrote:

On Tue, Mar 17, 2009 at 8:13 PM, Evan Gilbert <uid...@google.com> wrote:

http://codereview.appspot.com/28059

Suggested spec changed from original proposal:
- Think it makes sense to model the API after the very popular Firebug/WebKit logging API. Instead of gadgets.log(msg, level), the proposed API is gadgets.log(msg), gadgets.warn(msg), and gadgets.error(msg), in addition to gadgets.setLogLevel(level)
- Added gadgets.log.NONE as a logging level, to suppress logging entirely.

Other notes:
- console.log() in Firebug supports a list of arguments which are formatted as a string. However, this isn't supported in WebKit flavors, and I thought it best to leave out of the core API. Think this can be an implementation choice (to accept a list of parameters instead of the one message param)

We would want to be careful about this, as developers expecting multiple arguments to be logged on a system that didn't implement this would likely have most of their important logging information dropped (I typically use something like console.log("functionName", arg1, arg2); ).  I think we can just safely say that only one argument will be supported.

 

Agreed that the official API will be one argument. However I don't see harm in implementations doing pass thru - this is very useful if you do most of your testing on a single browser and know what you're doing.

[Evan Gilbert]

Spec changes up for review @ http://codereview.appspot.com/28153/show

[Kevin Marks]

On Tue, Mar 31, 2009 at 12:54 AM, Evan Gilbert <uid...@google.com> wrote:

On Mon, Mar 30, 2009 at 11:52 AM, Arne Roomann-Kurrik <kur...@google.com> wrote:

On Tue, Mar 17, 2009 at 8:13 PM, Evan Gilbert <uid...@google.com> wrote:

http://codereview.appspot.com/28059

Suggested spec changed from original proposal:
- Think it makes sense to model the API after the very popular Firebug/WebKit logging API. Instead of gadgets.log(msg, level), the proposed API is gadgets.log(msg), gadgets.warn(msg), and gadgets.error(msg), in addition to gadgets.setLogLevel(level)
- Added gadgets.log.NONE as a logging level, to suppress logging entirely.

Other notes:
- console.log() in Firebug supports a list of arguments which are formatted as a string. However, this isn't supported in WebKit flavors, and I thought it best to leave out of the core API. Think this can be an implementation choice (to accept a list of parameters instead of the one message param)

We would want to be careful about this, as developers expecting multiple arguments to be logged on a system that didn't implement this would likely have most of their important logging information dropped (I typically use something like console.log("functionName", arg1, arg2); ).  I think we can just safely say that only one argument will be supported.

 

Agreed that the official API will be one argument. However I don't see harm in implementations doing pass thru - this is very useful if you do most of your testing on a single browser and know what you're doing.

could we make it handle being passed a list or object as the single param and printing it too?
then Arne's case could work with a bit of extra bracketing:

gadgets.log(["functionName", arg1, arg2]);
 

[Scott Seely]

I think if we spec the behavior of logging such that this is true WRT behavior:

gadgets.log(someValue) == gadgets.log(gadgets.json.stringify(someValue))

 

 then the array mechanism is trivial to spec and implement.

 

From: opensocial-an...@googlegroups.com [mailto:opensocial-an...@googlegroups.com] On Behalf Of Kevin Marks
Sent: Tuesday, March 31, 2009 1:50 AM
To: opensocial-an...@googlegroups.com
Subject: [opensocial-and-gadgets-spec] Re: gadgets.log prototype

 

 

On Tue, Mar 31, 2009 at 12:54 AM, Evan Gilbert <uid...@google.com> wrote:

[Evan Gilbert]

On Tue, Mar 31, 2009 at 9:24 AM, Scott Seely <sSe...@myspace.com> wrote:

I think if we spec the behavior of logging such that this is true WRT behavior:

gadgets.log(someValue) == gadgets.log(gadgets.json.stringify(someValue))

For consoles that support object logging, we want to pass through the raw JS object / array. In Firebug this will allow you to click on the object to get an object browser view which is incredibly useful.

The goal of multiple arguments (gadgets.log(a,b,c)) is to support Firebug, where console.log(a,b,c) is not == log(concat(a,b,c)). I don't want to spec this because not all consoles support this behavior, however I think implementations should be free to do something useful with the additional arguments.

[Scott Seely]

Can you post the patch? Thinking through things at the spec level will bring clarity sooner.

[Evan Gilbert]

http://codereview.appspot.com/28153/show

[Scott Seely]

Instead of specifying how we work with parameters, let’s log the arguments array so that we support 1, 2, or more parameters with no issues. Would that be acceptable?

[Evan Gilbert]

On Tue, Mar 31, 2009 at 2:59 PM, Scott Seely <sSe...@myspace.com> wrote:

Instead of specifying how we work with parameters, let’s log the arguments array so that we support 1, 2, or more parameters with no issues. Would that be acceptable?

From an implementation perspective, I'm not sure if we know how to do this right across different loggers. To do this right you would call
console.log(a,b,c) for Firebug
console.log(gadgets.json.stringify(a) + gadgets.json.stringify(b) + gadgets.json.stringify(c)) for other loggers (for now, although their behavior could change).

Also, I'm not sure if we'll ever need positional params - possibly the right API will be gadgets.log(objectOrArray, loggingParam). Possible params would be a namespaced string so that you could selectively log, etc.

Seemed safer to start with the known API - one object param, and then wait for usage to work through these additional issues (how to log multiple arguments consistently and how to pass additional parameters to the logging system).

[Scott Seely]

Sounds fine—just digging in a bit.

 

Given the current construction, I’m confident we can be more expressive as we learn more.

[Adam Winer]

+1 to the one-arg approach (and the spec diff Evan provided).

[Evan Gilbert]

Think we're good to go with this change. Scott - we have the OK to commit? (Paul L was +1 also on a separate thread).

[Scott Seely]

Go fer it

[Arne Roomann-Kurrik]

Committed at http://code.google.com/p/opensocial-resources/source/detail?r=1082

~Arne