[gst-devel] INFO, DEBUG, and ERROR systems

[Erik Walthinsen]

I just committed the new INFO and ERROR subsystems to CVS.  Very little
code is converted to use them yet because we need to decide at a policy
level what kinds of events are responded to how.  Some things can get by
with a g_return_if_fail, but others can't.  How do we decide what can be
ignored and what has to fault the program, at least under the default
case?

Also, I started to look into using varargs to let us create our own printf
formats, like %O for an object.  I have code to parse and manipulate the
format string as necessary, but manipulating the varargs struct is much
harder, and something that shouldn't be done anyway.  The only option I
can see is to parse and respond to the format string ourselves, using
printf to handle the format oddities.

What this varargs trick might let us do is hook into the format string
mangling and allow error handlers to extract the interesting pointers
from the format string.  This would get rid of the fairly rigid approach
of:

ERROR(element,format,args...)
ERROR_OBJECT(element,object,format,args...)

We just go straight to:

ERROR(format,args...)

But then we'd want to put some restrictions on the error message formats,
i.e. the element(s) in question must come first.


As for the INFO system, there is no thresholding as of now.  Again, we
need to develop a policy as to what gets shown as INFO, and how we're
going to split them up into groups or levels.  The list of groups must be
created before any real work can begin as far as putting INFO everywhere.


I'm going to sleep now.

         Erik Walthinsen <omega at cse.ogi.edu> - Staff Programmer @ OGI
        Quasar project - http://www.cse.ogi.edu/DISC/projects/quasar/
   Video4Linux Two drivers and stuff - http://www.cse.ogi.edu/~omega/v4l2/
        __
       /  \             SEUL: Simple End-User Linux - http://www.seul.org/
      |    | M E G A           Helping Linux become THE choice
      _\  /_                          for the home or office user