[syslog-ng] [RFC]: value-pairs()

[Fekete Robert]

Gergely Nagy wrote:

>>> value-pairs (
>>>   glob-select ("usracct.*")
>>>   glob-exclude ("*.*id")
>>>   builtins (no)
>>>   $HOST $MESSAGE
>>>   "program_n_pid" = "$PROGRAM[$PID]"
>>> )
>>>
>> I would like to have the select/exclude take a style and an expression so that
>> the use of gnu regex could be used (if supported by syslog-ng) or perl regex
>> or glob. Perhaps only glob and perl regex are supported now but there may be
>> a faster regular expression tool that becomes available in the future that
>> could be added without breaking backwards compatibility.
>>
> 
> Part of the reason for the glob- is precisely due to this reason: so
> that other -select/-exclude styles can be added.
> 
> Instead of what you propose, we'd have pcre-select() or xpath-select()
> or whatever else there is need for.
> 
>> The use of $HOST or any other macro should always refer to the content of the macro,
>> so for the purpose of identifying macros by name, a syntax
>>
>>     macro (HOST MESSAGE)
>>
>> could be used. I think this is more intuitive than using the $HOST names.
> 
> That makes sense, thank you!
> 
>> Finally, each of these value-pairs definitions is of the form
>>
>>    keyword ( arguments )
>>
>> so for consistency I would suggest that defining custom keys should be done with something
>> of the format
>>
>>    define ( "program_n_pid", "$PROGRAM[$PID]")
>>
>> for complete orthogonal consistency this should be
>>
>>    define ( macro="program_n_pid", value="$PROGRAM[$PID]")
>>
>> but that may be a little bit of overkill.
> 
> Yeah, it would be. :)
> 
> I'd rather have something that might be a little bit inconsistent (eg,
> the glob-* stuff being the exception), yet expressive and not overly
> long, than something that's consistent, but too verbose.

Currently syslog-ng uses a type() option to specify glob/pcre/posix and so on, 
with posix being the default. Could we have a single select fuction and use the 
type option, just for the sake of consistency?

Robert

> 
> I do see your point, though, and thanks a lot for the ideas!
>