[Devel] Feature request: error/debug message extension.

[David Robillard]

On Thu, 2012-01-12 at 17:09 -0500, Paul Giblock wrote:
> > This would let the host do pretty much anything (by putting whatever in
> > the handle), but also make a trivial implementation extremely simple
> > (you could literally use pointers to printf and vprintf with a FILE*
> > handle if you just want to print to stdout anyway).
> 
> Yes, although the trivial solution is inherently not real-time safe.
> Good to still have the option for a host to be quick and careless
> though.

Making this real-time safe and callable from any context is not
realistic.  If logging from the audio thread is required we would
probably need to use several feature URIs (though the actual API could
be identical).

> > One thing this does not address, though, is multiple streams e.g. for
> > errors, warnings, and info messages.
> 
> I wonder if extensibility of the different streams is necessary or
> not? I'm thinking "no".  We could allow mapped URIs for the different
> streams, and predefine a few (error, warn, and info)?  But, if you
> study the popular Log4j or java.util.logging Java packages, it seems
> people are happy enough with: Fatal, Error, Warn, Info, Debug, Trace.
> I'm suggesting one more argument before the format string for the
> enumerated value of the stream. (The java logging packages seem to
> call these logging "levels").

Not having any at all seems a bit severely limited, I would think at the
very least error and info (i.e. not error) would be necessary.  It also
matches stdio.  Adding a stream parameter that's a URId seems a
reasonable solution, simple yet extensible.  I can't think of any good
reason why the host would have to associate completely different handles
with different streams (worst case scenario it can wrap it all up in one
object and do the same thing by dispatching on the URId anyway).

> Finally, I feel it is a good idea to support the format-string and
> varg variants. Not only are the plugins relieved from the duty of
> string-banging while in RT mode, but the host is able to short-circuit
> the whole thing should the level be under some threshold.

Definitely.  Anything that doesn't match printf would be insanity.  For
better or worse, this is C :)  The va_list is probably less commonly
needed, but it's generally a bad idea to provide a varargs function
without a corresponding va_list version.  A minor burden on hosts, but
an acceptable one, IMO. 

(Pragmatically, it is quite likely that existing plugin code already
uses printf, so porting would be easy.  Doing format strings yourself
would be a huge nuisance)

So I guess we have:

typedef void* LV2_Log_Handle;

typedef struct _LV2_Log {
    LV2_Log_Handle handle;

    int (*printf)(LV2_Log_Handle handle,
                  LV2_URID       level,
                  const char*    fmt, ...);

    int (*vprintf)(LV2_Log_Handle handle,
                   LV2_URID       level,
                   va_list        ap); 
} LV2_Log;

-dr