Details

    • Type: Sub-task Sub-task
    • Status: Reopened
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: Master
    • Fix Version/s: Master
    • Component/s: Plugin Console
    • Labels:
      None
    • Environment:

      Run Cordova/PhoneGap with Cordova-SQLitePlugin and some other plugins

      Description

      I got a pull request on my Cordova-SQLitePlugin with a special logging function that is only logging when built as a debug version. I believe this issue should be solved in the core with a log function that is only logging when built as a debug version. Ideally a logging facility with multiple log levels. Please forgive me if this has already been done somewhere.

        Issue Links

          Activity

          Hide
          Joe Bowser added a comment -

          This isn't applicable to Android, we never had a console.log plugin.

          Show
          Joe Bowser added a comment - This isn't applicable to Android, we never had a console.log plugin.
          Hide
          Chris Brody added a comment -
          Show
          Chris Brody added a comment - FYI I found a nice link for console.log() at: http://opensourcehacker.com/2011/03/15/everyone-loves-and-hates-console-log/
          Hide
          Chris Brody added a comment -

          I have now opened CB-623 to make it very clear that we need to separate the logger functionality from the console and leave these issues up to discussion in the community.

          Show
          Chris Brody added a comment - I have now opened CB-623 to make it very clear that we need to separate the logger functionality from the console and leave these issues up to discussion in the community.
          Hide
          Patrick Mueller added a comment -

          Pat: We create a new logger property on cordova. The primary use for this is plugin code, not "user land" code. cordova.logger will have whatever minimal logging level stuff we need.

          Chris: Why restrict the primary use to plugins?

          Because we need to expose this loggingLevel functionality in a new object. But plugin authors already have to deal with the cordova object for other uses. Might as well put it there. We don't really advertise cordova as being something that user land JavaScript should be using (I don't think).

          And, in general, we should be wary of creating "new API", at least API visible to user land JavaScript. Every "API" that we create from here on out will be painful to remove in the future.

          Maybe this new logging facility will pass muster over time and we can declare it API and support it forever everywhere. But I've never seen any suggestion that the existing de facto standard console object needed this functionality, so history would say YAGNI (in user land JavaScript).

          Show
          Patrick Mueller added a comment - Pat: We create a new logger property on cordova. The primary use for this is plugin code, not "user land" code. cordova.logger will have whatever minimal logging level stuff we need. Chris: Why restrict the primary use to plugins? Because we need to expose this loggingLevel functionality in a new object. But plugin authors already have to deal with the cordova object for other uses. Might as well put it there. We don't really advertise cordova as being something that user land JavaScript should be using (I don't think). And, in general, we should be wary of creating "new API", at least API visible to user land JavaScript. Every "API" that we create from here on out will be painful to remove in the future. Maybe this new logging facility will pass muster over time and we can declare it API and support it forever everywhere. But I've never seen any suggestion that the existing de facto standard console object needed this functionality, so history would say YAGNI (in user land JavaScript).
          Hide
          Chris Brody added a comment -

          Do you mean the JS console object that is currently visible to most every web browsing widget available? Or do you mean the "Debug Console" Cordova plugin?

          Both.

          We create a new logger property on cordova. The primary use for this is plugin code, not "user land" code. cordova.logger will have whatever minimal logging level stuff we need.

          Why restrict the primary use to plugins?

          We'll rename the "Debug Console" plugin to "Logger", or whatever.

          Sounds better, get rid of the space in the middle.

          For platforms that do not have a console object visible in user-land JS, or the one that's provided is sub-par or non-operational (iOS), provide an implementation of the FireBug Console API implemented with the new cordova.logger object.

          Sounds like a good option.

          This leaves us with a portable, common, non-extended console object for userland JavaScript. Something users are familiar with. They won't be confused when they see our console has sprouted new methods. Nor will they inadvertently leave invocations of this extended console API in their code, only to find it throws exceptions outside of Cordova.

          So you are saying keep console as-is because it is already a HTML standard API. Now I get it.

          For plugin authors who are doing boat-loads of logging and therefore need lots of control, they can use the cordova.logger object.

          Unfortunately regular app authors are becoming forced to act as plugin authors and fixers when they need some native functionality, for which no one has made the plugin yet, or the relevant plugin does not cover the required functionality 100%.

          I think the real issue and conclusion we are finding is that we do have to make a clean separation between what is HTML compliant in the console object and what only works for native in cordova.logger. It took me until reading your last comment to understand.

          Show
          Chris Brody added a comment - Do you mean the JS console object that is currently visible to most every web browsing widget available? Or do you mean the "Debug Console" Cordova plugin? Both. We create a new logger property on cordova . The primary use for this is plugin code, not "user land" code. cordova.logger will have whatever minimal logging level stuff we need. Why restrict the primary use to plugins? We'll rename the "Debug Console" plugin to "Logger", or whatever. Sounds better, get rid of the space in the middle. For platforms that do not have a console object visible in user-land JS, or the one that's provided is sub-par or non-operational (iOS), provide an implementation of the FireBug Console API implemented with the new cordova.logger object. Sounds like a good option. This leaves us with a portable, common, non-extended console object for userland JavaScript. Something users are familiar with. They won't be confused when they see our console has sprouted new methods. Nor will they inadvertently leave invocations of this extended console API in their code, only to find it throws exceptions outside of Cordova. So you are saying keep console as-is because it is already a HTML standard API. Now I get it. For plugin authors who are doing boat-loads of logging and therefore need lots of control, they can use the cordova.logger object. Unfortunately regular app authors are becoming forced to act as plugin authors and fixers when they need some native functionality, for which no one has made the plugin yet, or the relevant plugin does not cover the required functionality 100%. I think the real issue and conclusion we are finding is that we do have to make a clean separation between what is HTML compliant in the console object and what only works for native in cordova.logger . It took me until reading your last comment to understand.
          Hide
          Patrick Mueller added a comment -

          log4j

          As someone who has suffered with log4j and it's "successors" over the years, you're not convincing me.

          I'm still missing some precision here. What does this mean?

          add the missing functionality to the existing class

          Do you mean the JS console object that is currently visible to most every web browsing widget available? Or do you mean the "Debug Console" Cordova plugin?

          I'm reading what you're saying is that you want to standardize the additional methods/properties that the iOS version has added to the JS console object, across all the platforms. In which case ...

          If we have to add a new class every time something is missing, we will start a path that has more and more plugins and source files. This is not a good way forward either, since constantly adding classes will add complexity and more than one way of doing each thing.

          I'm not suggesting we add any additional plugins, assuming we re-use or retro-fit the "Debug Console" plugin. We don't need an additional plugin or source file to expose methods on an new JavaScript object. We're only exposing a new object in JS.

          Also, you're already suggesting "more than one way of doing each thing". My understanding is that the existing JavaScript console object actually works in most of the Cordova runtimes, in various flavors. Do we really want to "patch" console.info() to take into account the current logging level? Now you're changing existing behavior!

          Here's my suggestion, based on guesses on your use case.

          We create a new logger property on cordova. The primary use for this is plugin code, not "user land" code. cordova.logger will have whatever minimal logging level stuff we need. We'll rename the "Debug Console" plugin to "Logger", or whatever.

          For platforms that do not have a console object visible in user-land JS, or the one that's provided is sub-par or non-operational (iOS), provide an implementation of the FireBug Console API implemented with the new cordova.logger object.

          This leaves us with a portable, common, non-extended console object for userland JavaScript. Something users are familiar with. They won't be confused when they see our console has sprouted new methods. Nor will they inadvertently leave invocations of this extended console API in their code, only to find it throws exceptions outside of Cordova. For plugin authors who are doing boat-loads of logging and therefore need lots of control, they can use the cordova.logger object.

          Show
          Patrick Mueller added a comment - log4j As someone who has suffered with log4j and it's "successors" over the years, you're not convincing me. I'm still missing some precision here. What does this mean? add the missing functionality to the existing class Do you mean the JS console object that is currently visible to most every web browsing widget available? Or do you mean the "Debug Console" Cordova plugin? I'm reading what you're saying is that you want to standardize the additional methods/properties that the iOS version has added to the JS console object, across all the platforms. In which case ... If we have to add a new class every time something is missing, we will start a path that has more and more plugins and source files. This is not a good way forward either, since constantly adding classes will add complexity and more than one way of doing each thing. I'm not suggesting we add any additional plugins, assuming we re-use or retro-fit the "Debug Console" plugin. We don't need an additional plugin or source file to expose methods on an new JavaScript object. We're only exposing a new object in JS. Also, you're already suggesting "more than one way of doing each thing". My understanding is that the existing JavaScript console object actually works in most of the Cordova runtimes, in various flavors. Do we really want to "patch" console.info() to take into account the current logging level? Now you're changing existing behavior! Here's my suggestion, based on guesses on your use case. We create a new logger property on cordova . The primary use for this is plugin code, not "user land" code. cordova.logger will have whatever minimal logging level stuff we need. We'll rename the "Debug Console" plugin to "Logger", or whatever. For platforms that do not have a console object visible in user-land JS, or the one that's provided is sub-par or non-operational (iOS), provide an implementation of the FireBug Console API implemented with the new cordova.logger object. This leaves us with a portable, common, non-extended console object for userland JavaScript. Something users are familiar with. They won't be confused when they see our console has sprouted new methods. Nor will they inadvertently leave invocations of this extended console API in their code, only to find it throws exceptions outside of Cordova. For plugin authors who are doing boat-loads of logging and therefore need lots of control, they can use the cordova.logger object.
          Hide
          Chris Brody added a comment -

          > Can you be more precise with "keep the console logging in one place"?
          >
          > I assume you mean, "keep all the console-related methods in a single object - the console object".
          >
          > Meaning, bolt on new methods to a pre-existing object that we don't necessarily have control over.

          The original console logging functionality, as accessed via console.log(), works pretty well but has proven not to be perfect. I think we all understand that the idea of logging is to very quickly understand important events that are going on and also what event may cause or indicate a form of malfunctioning. I suspect the original authors decided not to spent valuable development time dealing with multiple logging levels.

          It has been proven necessary to have multiple logging levels. Of course this is not new; log4j has been doing this for years, UNIX and VMS have been doing this for decades.

          So we have a console logging facility that is pretty good but of course not perfect, and we have clearly identified a need to add multiple logging levels. IMHO the cleanest way forward is to add the missing functionality to the existing class and go forward. The default behavior for the old, existing function should be to continue to act the same, unless changed by configuration.

          If we have to add a new class every time something is missing, we will start a path that has more and more plugins and source files. This is not a good way forward either, since constantly adding classes will add complexity and more than one way of doing each thing.

          Show
          Chris Brody added a comment - > Can you be more precise with "keep the console logging in one place"? > > I assume you mean, "keep all the console-related methods in a single object - the console object". > > Meaning, bolt on new methods to a pre-existing object that we don't necessarily have control over. The original console logging functionality, as accessed via console.log(), works pretty well but has proven not to be perfect. I think we all understand that the idea of logging is to very quickly understand important events that are going on and also what event may cause or indicate a form of malfunctioning. I suspect the original authors decided not to spent valuable development time dealing with multiple logging levels. It has been proven necessary to have multiple logging levels. Of course this is not new; log4j has been doing this for years, UNIX and VMS have been doing this for decades. So we have a console logging facility that is pretty good but of course not perfect, and we have clearly identified a need to add multiple logging levels. IMHO the cleanest way forward is to add the missing functionality to the existing class and go forward. The default behavior for the old, existing function should be to continue to act the same, unless changed by configuration. If we have to add a new class every time something is missing, we will start a path that has more and more plugins and source files. This is not a good way forward either, since constantly adding classes will add complexity and more than one way of doing each thing.
          Hide
          Chris Brody added a comment -

          Sorry I just edited a couple old comments to reference the correct issue numbers (CB-617 CB-618 CB-619), thanks to @pmueller for asking in private.

          Show
          Chris Brody added a comment - Sorry I just edited a couple old comments to reference the correct issue numbers ( CB-617 CB-618 CB-619 ), thanks to @pmueller for asking in private.
          Hide
          Patrick Mueller added a comment -

          Can you be more precise with "keep the console logging in one place"?

          I assume you mean, "keep all the console-related methods in a single object - the console object".

          Meaning, bolt on new methods to a pre-existing object that we don't necessarily have control over.

          aka "money patch": http://en.wikipedia.org/wiki/Monkey_patch

          I'd also like to understand the use case here. You mention it being for a plugin you've written. Is this logging exposed to users of the plugin, or just folks developing the plugin?

          Show
          Patrick Mueller added a comment - Can you be more precise with "keep the console logging in one place"? I assume you mean, "keep all the console-related methods in a single object - the console object". Meaning, bolt on new methods to a pre-existing object that we don't necessarily have control over. aka "money patch": http://en.wikipedia.org/wiki/Monkey_patch I'd also like to understand the use case here. You mention it being for a plugin you've written. Is this logging exposed to users of the plugin, or just folks developing the plugin?
          Hide
          Chris Brody added a comment -

          My vote is to keep the console logging in one place with a cleaned-up *and documented* API.

          Show
          Chris Brody added a comment - My vote is to keep the console logging in one place with a cleaned-up * and documented * API.
          Hide
          Chris Brody added a comment -

          In a comment from Shazron it appears that we need to track the issue with the affected component(s). I raised this issue specifically to request multiple logging levels for iOS, since I didn't know that it was already supported for iOS. The others 117-119 are to make it clear that (a) we need to fix a problem in the JS, (b) consistent with the other platforms, and (c) properly documented.

          Show
          Chris Brody added a comment - In a comment from Shazron it appears that we need to track the issue with the affected component(s). I raised this issue specifically to request multiple logging levels for iOS, since I didn't know that it was already supported for iOS. The others 117-119 are to make it clear that (a) we need to fix a problem in the JS, (b) consistent with the other platforms, and (c) properly documented.
          Hide
          Chris Brody added a comment -

          I am reopening this issue because there does not appear to be proper agreement how/where to put the console logging level functionality.

          Show
          Chris Brody added a comment - I am reopening this issue because there does not appear to be proper agreement how/where to put the console logging level functionality.
          Hide
          Patrick Mueller added a comment -

          Kinda curious what the relation is between this issue, and the three that were just referenced (117-119).

          Show
          Patrick Mueller added a comment - Kinda curious what the relation is between this issue, and the three that were just referenced (117-119).
          Hide
          Patrick Mueller added a comment -

          So, this isn't great. You're saying we've added all this junk to the console object?

          I think what we need is a different object, to put this goop.

          Show
          Patrick Mueller added a comment - So, this isn't great. You're saying we've added all this junk to the console object? I think what we need is a different object, to put this goop.
          Hide
          Chris Brody added a comment - - edited

          This is not a problem in the iOS tree, I have now raised [...] to fix in the other places. (EDIT: CB-617 CB-618 CB-619)

          Show
          Chris Brody added a comment - - edited This is not a problem in the iOS tree, I have now raised [...] to fix in the other places. (EDIT: CB-617 CB-618 CB-619 )
          Hide
          Chris Brody added a comment - - edited

          I have now raised [...] so I will try closing this one. (EDIT by chbrody: CB-617 CB-618 and CB-619)

          Show
          Chris Brody added a comment - - edited I have now raised [...] so I will try closing this one. (EDIT by chbrody: CB-617 CB-618 and CB-619 )
          Hide
          Shazron Abdullah added a comment -

          "Debug Console" --> That's a cross-platform CordovaJS issue and should be brought up in another issue. Users won't see this abstraction anyway.

          Usually we document these things if they exist on all platforms, right now it is iOS only. Another Docs issue should be filed.

          Show
          Shazron Abdullah added a comment - "Debug Console" --> That's a cross-platform CordovaJS issue and should be brought up in another issue. Users won't see this abstraction anyway. Usually we document these things if they exist on all platforms, right now it is iOS only. Another Docs issue should be filed.
          Hide
          Chris Brody added a comment -

          OK so this really should be documented. Also, it seems error-prone for this plugin to register itself with a space in the middle of the name "Debug Console".

          Show
          Chris Brody added a comment - OK so this really should be documented. Also, it seems error-prone for this plugin to register itself with a space in the middle of the name "Debug Console".
          Hide
          Shazron Abdullah added a comment -

          Unofficially, in iOS there is already different logging levels: https://github.com/apache/incubator-cordova-js/blob/master/lib/ios/plugin/ios/console.js

          console.warn, console.error, console.log.

          To set the log level, you would set this somewhere in your code to one of these levels:
          https://github.com/apache/incubator-cordova-js/blob/master/lib/ios/plugin/ios/console.js#L13

          console.setLevel(console.ERROR_LEVEL);
          
          Show
          Shazron Abdullah added a comment - Unofficially, in iOS there is already different logging levels: https://github.com/apache/incubator-cordova-js/blob/master/lib/ios/plugin/ios/console.js console.warn, console.error, console.log. To set the log level, you would set this somewhere in your code to one of these levels: https://github.com/apache/incubator-cordova-js/blob/master/lib/ios/plugin/ios/console.js#L13 console.setLevel(console.ERROR_LEVEL);
          Hide
          Chris Brody added a comment -
          Show
          Chris Brody added a comment - Page from the gwt-phonegap project: http://code.google.com/p/gwt-phonegap/wiki/LoggingModule

            People

            • Assignee:
              Patrick Mueller
              Reporter:
              Chris Brody
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:

                Time Tracking

                Estimated:
                Original Estimate - 48h
                48h
                Remaining:
                Remaining Estimate - 48h
                48h
                Logged:
                Time Spent - Not Specified
                Not Specified

                  Development