Cool, thanks for organizing this sensibly Pat! On 5/3/12 9:49 AM, "Patrick Mueller" <[email protected]> wrote:
>I'm going to start in on the console/logger issues: > > console object improvements > https://issues.apache.org/jira/browse/CB-348 > > Logging levels > https://issues.apache.org/jira/browse/CB-611 > > Debug Console registers itself with an error-prone name > https://issues.apache.org/jira/browse/CB-617 > > Support DebugConsole plugin for all platforms > https://issues.apache.org/jira/browse/CB-618 > > Document how to use logging levels from Debug Console > https://issues.apache.org/jira/browse/CB-619 > > Logger functionality separated from (debug) console > https://issues.apache.org/jira/browse/CB-623 > >Here's the basic idea: > >- create a new module/object exposed on cordova called logger >- like log4j but smaller/simpler/sensible >- default implementation in common/logger.js that writes all output via >console.log() >- if a platform has something better to implement to, override logger.js >in >your platform subdirectory >- iOS has something better to implement to, so will use that as the first >'native logger' implementation, and so the initial take at a Logger plugin >interface (that other platforms could implement to). >- intended for use by plugin developers today, maybe we can expose it to >app developers later > >Then there's console. Not every platform exposes a "global" console >object. iOS and at least one of the blackberries. We should provide an >implementation which matches the de facto standard Firebug Console API, >and >delegates to the logger if it's implemented. > >We'd never run into infinite loops with this. Never. :-) > >I'll add some logic to the loggers/consoles so that we can ensure that >after they've been initialized, that both are not implemented as calling >into the other. > >-- >Patrick Mueller >http://muellerware.org
