Verbosio

XPCOM and Logging, part 2

2 Comments

First off, thanks to everyone who took the time to reply to my original blog post. Several people pointed me to moz4js, and I’m quite pleasantly surprised to find out the Mozilla Thunderbird team uses it quite a bit. I hadn’t heard of it, but when I did through the comments, I found it had the same problem NSPR logging has: single language support.

Then I realized: if we put moz4js in a JavaScript module, then a component can reference that module and expose the same interfaces to XPCOM. Chrome JS and JS components can load the module, and all other languages can use the XPCOM component. Maybe not simple, but certainly workable.

No, I’m not signing up to own the toolkit moz4js bug. I’m not wholly convinced, personally, it’s the right way to do logging. What I do think, though, is that we need a general discussion on logging API’s and consumers.

In the bug, Flock mentioned their own API – which I also didn’t know about. I mentioned Skyfire has an internal logging system. It makes me wonder how many other companies and projects (Songbird, Komodo, Disruptive Innovations, etc.) have implemented their own logging API’s. This is one subject that reasonably affects the whole Mozilla developer community.

If MozPad were still active, this is one subject I’d put right to them and develop a standard logging API for. Since we don’t have MozPad anymore, I would like to put it to the community at large:

  1. What do you require logging for?
  2. What logging capabilities do you need?
  3. What logging infrastructure (API, code) have you already implemented or used?
  4. What tests exist and pass for the logging infrastructure you use?
  5. How extensively do you use your logging infrastructure?
  6. How easy is it to work with your logging infrastructure?
  7. If you use someone else’s logging infrastructure, what’s missing?
  8. Are you willing to work on getting your logging infrastructure into the Mozilla code base? (Writing code, tests, specifications)
  9. Are you willing to work on developing a common Mozilla standard logging API and infrastructure, and getting that into the Mozilla code base? (Writing code, tests, specifications)
  10. Are you willing to actively “own” and drive an effort towards adding a Mozilla standard logging API to the Mozilla code base?

Please reply in the comments. The quality and quantity will tell me how seriously I should be taking this.

(P.S. I found a bug in my logging interfaces already. Not the JavaScript code, but the IDL. Bonus points to the first person to spot it besides me – it’s a little undocumented gotcha.)

2 thoughts on “XPCOM and Logging, part 2”

  1. A potential gotcha is that you shouldn’t advertise that you’re returning an nsIMultiplexInputStream. Instead you should just declare the return type as an nsIInputStream. Anyone who wants to multiplex your stream can create their own nsIMultiplexInputStream anyway.

  2. Firebug has an extensive internal logging system and of course supports Web page logging via Firebug’s window.console object.
    The internal logging API is a string followed by an optional object. Originally I had other variations, but for a complex system they just get in the way. The optional object adds a lot of flexibility, eg you can create a temp object with properties based on your needs. One effective case is exceptions: we print a string+exc to give the text of the error, then follow up with the object for more details.
    In both the internal and Web page cases the objects logged are linked back into the Firebug or Chromebug. So for example, if you log an HTML element, then you can mouse over the element to see it highlighted in the page or window.
    jjb

Comments are closed.