[syslog-ng] [RFC] value-pairs(), take #3

[Gergely Nagy]

On Mon, 2011-02-07 at 08:54 -0800, Evan Rempel wrote: 
> > 
> > value-pairs(
> >   scope(selected_macros nv_pairs)
> >   select(.*)
> >   select("usracct.*")
> >   select("secevt.*")
> >   select(".SDATA.*")
> >   exclude("*")
> >   key("SEVERITY") key("HOST") key("PROGRAM") key("PID")
> >   key("MSG") key("TAGS")
> >   pair("timestamp" "$UNIXTIME")
> > );
> 
> I think I've realized why I have so much trouble with the meaning of
> this stanza.
> 
> I think that you are approaching this as a filter of the keys.
> When doing this the first filter that "matches" the key is the one that
> actually determines if the key is included or not.

Yep, that is the intent.

> I approach this as a set theory specification. In set theory, it is
> the last item that determines if a key is included.
> 
> Both are equally flexible and non-ambiguous. My preference for this
> type of task is to use set theory. I view this as building a set of
> keys to place into the output template.
> 
> I find the following a lot more intuitive.
> 
> value-pairs(
>    scope(selected_macros nv_pairs)
>    exclude("*")
>    select("secevt.*")
>    select("usracct.*")
>    select(.*)
>    key("SEVERITY") key("HOST") key("PROGRAM") key("PID")
>    key("MSG") key("TAGS")
>    pair("timestamp" "$UNIXTIME")
> );
> 
> 
> select(".SDATA.*") isn't needed because it matches the select(.*) anyway.

I see your point, and it makes sense. From an implementation point of
view - as you point out in a later mail - it doesn't matter much, I'd
just have to start at the other end of the list.

The more I think about it, the more I like your way of thinking.

> If you opt for the filter approach then the docs will have to be clear in stating that the
> select and include are final filters. selects or excludes following will have no affect.

If we end up with filter approach, it will be properly documented, yep.

On the flip side, if this is the only complaint against the current
proposal, that's great news, as I can go ahead and implement it!
Switching between the two approaches (from a code point of view) is
trivial, and can be decided later.

-- 
|8]