What API for a new logging facility for mozilla?
Mike Hommey
In my quest to get rid of static initializers, a few of them appear to
be due to log modules initialization with PR_NewLogModule. While
avoiding the static initializers can probably done without too much
disruption, I thought it would be a great occasion to tackle some of the
longstanding issues with logging within the mozilla codebase (such as,
to name one bug I'm aware of, 237326).
I would thus like to add a new logging API with the following
properties:
- no static initializers (obviously)
- same runtime overhead as prlogging.
- compatibility API to minimize migration cost (I'm also tempted to
highjack the prlog functions ; this should work on linux (depending
how nspr is linked), but I don't know about other platforms)
- better output (I think at least adding the module and the level
would be nice) ; a possibility to capture the output from inside
gecko would be good, too.
- allow to dynamically change log levels
This could also be the occasion to add some sugar on top with ostream
like << syntax (I'm not entirely convinced using iostreams themselves
would be good, though).
Do you see anything missing in the above feature list, or do you have
some objections before I start?
Cheers,
Mike
David Bienvenu
Glad to see you're doing this!
> - allow to dynamically change log levels
standpoint.
- David
David Byron
>
> I would thus like to add a new logging API with the following
> properties:
> - no static initializers (obviously)
> - same runtime overhead as prlogging.
> - compatibility API to minimize migration cost (I'm also tempted to
> highjack the prlog functions ; this should work on linux (depending
> how nspr is linked), but I don't know about other platforms)
> - better output (I think at least adding the module and the level
> would be nice) ; a possibility to capture the output from inside
> gecko would be good, too.
>
> like<< syntax (I'm not entirely convinced using iostreams themselves
> would be good, though).
>
> Do you see anything missing in the above feature list, or do you have
> some objections before I start?
It would be nice to support some kind of callback so apps can get called
with each log message (and its level) and send them wherever, perhaps to
a file shared with the rest of the app.
Apologies if this is part of the existing code or plan already. I just
started working on an app that embeds gecko and am slowly coming up to
speed.
Thanks much.
-DB
Wayne Mery
Indeed, such a feature will greatly simplify the ability to help
non-technical users with technically involved problems. The current
logging capability is also a barrier to productivity in the debugging world.
As far as UI:
- the grand-daddy bug I think is SeaMonkey Bug 193873 - Add Mozilla
logging to UI.
- Bug 492620 - better, easier logging/diagnostics for Thunderbird - has
jcranmer's notes on doing this with Gecko 2.0
Titillating side items:
Bug 342368 - Need a way to append to the log file
Bug 386218 - make debug/trace logging circular and automatic
--
QA/bugzilla advice ...
http://www.mibbit.com/chat/?server=irc.mozilla.org&channel=#tb-qa
evangelize ... http://www.spreadthunderbird.com/aff/165/
you can help with ... http://wiki.mozilla.org/Thunderbird:Testing
JJ
> properties:
Under electrolysis, we also have the issue of multiple processes
logging at the same time. It'd be nice to have a single interleaved
log, but I'm not sure that simple printf's work for that on all
platforms (see https://bugzilla.mozilla.org/show_bug.cgi?id=534764),
but a logging service could make it work.
JJ
> properties:
Under electrolysis, we also have the issue of multiple processes