Re: Proposal for 2.8: Glog

[Maciej Katafiasz <ml mathrick org>]

Dnia 04-05-2005, śro o godzinie 09:15 -0400, Matthias Clasen napisał:
> > > > here's a proposal for addition to Glib 2.8, named Glog.
> > > > Bunch of details:
> > > 
> > > The two immediate questions I have:
> > > 
> > > - How does this relate to the existing GLib logging facility
> > >   (g_log, g_warning, etc) ?
> > 
> > It's complementary. Existing logging is mostly for detecting and
> > reporting programming errors, and is not intended for heavy-duty tracing
> > of normal execution. 
> 
> Where did you find that g_log mission statement ?

Mission statement? It's simple observation of what they are used and
useful for. Granted, I'm not their developer and cannot know what they
were originally intended for, but I'd be surprised if tracing code
execution was one of the goals. They simply aren't suited for that.

> > Glog has flexible filtering of shown info, and
> > supports notion of categories, which makes it usable for dealing with
> > excessive amounts of data tracing tends to generate.
> 
> If log categories are valuable, how about adding simple category support
> to g_log, instead of adding a clone of the (IMO) somewhat overengineered
> log4x stuff ?

Umm. Glog isn't clone of anything, and honestly, I don't care single bit
if that log4x is overengineered or not. It is results of GStreamer needs
over the years, and everything in Glog is there because someone needed
it badly enough to code the feature. I only mentioned log4j because it
has similar application domain and I am (vaguely) familiar with its
purpose. Nothing more, no architectural implications of any kind.

If you think that there's no way Glog and glib debugging can live side
by side, fine, but IMHO --g-fatal-warning and similar stuff suggests
otherwise.

> > > - What do we win by putting yet another log4x clone into 
> > >   Glib instead of simply using log4c ?
> > 
> > Dunno what log4c is :). What we win by Glog is closely coupled with Glib
> > piece of code (it's not as much a separate library as extension to
> > Glib), following the same design, and known to work very well with
> > Glib-based code. Also, it's thoroughly tested, known to work on every
> > platform Glib works on, and you know the maintainers, so know who to
> > beat up when something goes wrong ;)
> 
> You should probably google for log4j, log4c, log4c++, etc then, to learn
> what you are proposing as a GLib addition, then.

Umm. Why would googling for anything give me idea about Glog? I am not
in the search for logging library, nor did I say "hey guys, let's write
logging library". I am proposing small piece of code that exists right
now and blends damn well into Glib as it stands today, because it was
written as Glib extension someone (the GStreamer team) felt was missing,
and someone (Benjamin) libified for easy inclusion. You're reading way
too much stuff I haven't written anywhere in my mail.

There seems to be misunderstanding somewhere that needs to be resolved.
Glog was written and proposed because it's proven to be useful for us,
and we believe will be useful for other people too. That's it, nothing
more, no big philosophy behind it :)

Cheers,
Maciej

-- 
Maciej Katafiasz <ml mathrick org>