On 14/02/12 08:58 +0000, Dietmar Maurer wrote:
> I am totally open to that, in fact I did have that at one point
but others wanted a
> "higher level api".
But what is the advantage of such API?
I am not sure one is much better than the other. Just setter vs. callback.
The callback is probably more flexable.
> So to define the behavior:
>
> qb_log_filter_fn_set(target, my_filter_fn);
>
> This will immediatly call my_filter_fn with all currently know callsites.
I am not sure if we talk about the same thing.
That should not call my_filter_fn() immediately. Instead my_filter_fn() should
be called before something gets logged - log is discarded if that function returns false.
I am not sure if you understand the callsites, so I'll explain just in case:
When you log a "struct qb_log_callsite" is created (there is 2 ways this can
happen - I won't go into that now). But for every log you have in your program
there is a "struct qb_log_callsite" instance in the logging system.
When you call filter_ctl() it goes through all those instances and applies
the filter by comparing the filter to the callsite and writing to The
target field.
Then when you log a message the target is already set and it knows what
to do with the message.
The point is to do the expensive "filtering" upfront (so strcmp's etc).
It is faster especially through time critical sections when the same
debug or trace logs are called repeatedly.
> It and call
> it later if there are new ones.
>
> If there is a change to your logic in my_filter_fn then just call
> qb_log_filter_fn_set() again.
yes.
> How is that?
>
> I can't drop the other functions now.
I guess we can have both APIs without problems?
- Dietmar
_______________________________________________
quarterback-devel mailing list
quarterback-devel(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/quarterback-devel