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

[David Robillard]

On Sat, 2012-01-14 at 17:52 -0600, Gabriel M. Beddingfield wrote:
> On 01/14/2012 02:48 PM, David Robillard wrote:
> >> a. Adopt sprintf() syntax, which I don't believe can be implemented
> >>      in a RT-safe manner.
> [snip]
> >
> > Obviously standard syntax would be used.
> >
> > It is certainly possible to implement in an RT-safe manner, though the
> > stdlib functions may not be.
> 
> So we want to put *THAT* complexity on the host??

If we must choose, yes!  Obviously.  I don't see why the heck you think
it's better to have it in the plugins... 

> > Regardless, that argument is basically "this is hard, so we should force
> > plugins to do it", which is backwards.  Like it or not, code is going to
> > have to do format-string-like things in order to print anything useful.
> > To say otherwise is like saying "nobody will need to print numbers".
> 
> OK, but the plugin can use a simplified syntax for dynamic strings.
> 
> Proof of concept:  RtString<T> 
> http://gitorious.org/composite/composite-labs/blobs/master/200912-rtstring/RtString.hpp

I can swallow restrictions, though I don't particularly like the idea of
having to specify it.  An existing spec for this to point to would be
nice...

> >> That's why I suggest that a callback to the plugin (or an event) is
> >> required.  When the logging level changes, the plugin is notified of the
> >> change.
> >
> > I guess this would do.  Yet more complexity...
> 
> ...and optional complexity on the part of the plugin.  If they want to 
> use a slow-ass query function, they can have at it.

Since I see no other way of doing it, this is fine.  Note it's more
complex than having a single logging level, you'd have to store whether
each log level you use is enabled independently since the levels aren't
in a "tower".

> > As always, where there is a choice, complexity belongs in the host.
> > Making every plugin include a realtime-safe printf implementation would
> > be absurd.
> 
> The plugins have the option of NOT using printf & co. for their 
> strings... but can still have string formatting.

This seems to keep coming back to admitting this complexity is required,
and you proposing it belongs in each and every plugin rather than the
host.  I do not agree, and I will never agree, without a really good
argument to convince me otherwise.

There are vastly more plugins than hosts, and there are vastly more new
developers who want to dive in to plugin writing than people who want to
(or need to) write a host.  Code duplication is the best universal
metric for bad design decision I know of.  Offsetting all of that
requires good reasons.  The cons are obvious (they are the ones that
always apply, which is why "complexity belongs in the host" is an LV2
maxim and the default position).  *Why* do you think this is better?

-dr