Rainer Gerhards wrote:
>> -----Original Message----- From: [email protected]
>> [mailto:rsyslog- [email protected]] On Behalf Of Mr.
>> Demeanour Sent: Friday, June 25, 2010 9:03 AM To: rsyslog-users
>> Subject: Re: [rsyslog] feedback requested: NEW rsyslog.conf format
>> -- XML?
>>
>> Mr. Demeanour wrote:
>>> Hmmm. It struck me a few-dozen posts back in this thread that the
>>> configfile language perhaps *needs* to be a full language.
>>>
>>> Many perl and PHP apps have config files that are really data
>>> declarations in perl or PHP; I thought of suggesting a configfile
>>> written in perl. Then I reconsidered.
>>>
>>> Could you elaborate your objection to using JSON? you say you
>>> "question" it, but we haven't seen your question.
>>>
>> Apologies for commenting on my own post.
>>
>> I note the objections to XML as a configuration language. Generally
>> these seem to be concerned with the difficulty of reading and
>> editing XML "as she is wrote", i.e. a UTF-8 document full of <>
>> crows-feet, with tags, attributes, processing-instructions,
>> namespace-declarations and all that.
>>
>> I'm not sure if I'm being technically correct; but the essence of
>> an XML document is a DOM tree, not any specific rendition of that
>> tree. Given some restricted XML-based notation (such as the
>> notation for an rsyslog configuration, for example) there's no
>> intrinsic reason why the XML document shouldn't be 'flattened' for
>> storage, and represented as something like an INI file. For config
>> data, I favour flatness. I don't think it's at all a good idea to
>> be able to express if/then/else constructs in a config file; that
>> belongs in the code. The configuration should be a static thing.
>
> It's not the configuration that needs if-then-else in the sense that
> some part of the config is used versus another. It is that the
> configuration needs to specify rule execution (filters!) and these
> have an if-then-else structure. In fact, that was quite often
> requested and the current discard action is a work-around for some of
> the use cases.
>
> So we need to differentiate between
>
> a) if-then-else in the config language for config purposes and b)
> if-then-else for building rulesets (which then essentially become
> ruletrees vs. the rulelists they are today)
>
> I agree that a) is probably not desirable, but b) is essential. It is
> this argument that I have against using Lua, which IMHO addresses
> only a), which is not needed at least.
Some few-dozen messages ago, you posted this:
> if $source = 'host1' then do action 1 do action 2 if $msg contains
> 'error then do action 3 end if do action 4 else do action 5 end if
You could express that in XML something like this:
<eq target="$source" value="host1">
<action value="1" />
<action value="2" />
<contains target="$msg" value="error">
<action value="3" />
</contains>
<action value="4" />
<nomatch>
<action value="5" />
</nomatch>
</eq>
I don't know if that helps. It's no more long-winded than your version.
But I think I'd prefer not to see explicit if/then/else constructs in a
config file.
I'm not partiuclarly happy with my version either, because it is really
just masking the if/then/else as XML document structure.
If the requirement really is for the config to express the sense of an
if/then/else structure, and also to express ordered sequences of
operations, then that *is* a programming language, and we shouldn't try
to pretend that it's a config file. You should use a scripting language
for that.
My feeling is that perhaps you should consider using both mechanisms at
the same time; actions and simple rules can be defined as at present, in
a flat config file; and if the user has a requirement for a scripted
rule, then they are obliged to write it as script. But the script isn't
part of the config; perhaps the config can refer to the external
scripted rule by name, or something like that.
You might actually ship a default file of scripted rules, that the
default config refers to.
* The flatfile config needs to be able to refer to scripted rules by
name, if only to attach a scripted rule(set) to some input.
* The scripted rules need to be able to refer to the flatfile config,
because that is where actions would be defined.
So you'd need to load both files before you could validate either. Awkward.
--
MrD.
_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com
