> > -----Original Message-----
> > From: [email protected] [mailto:rsyslog-
> > [email protected]] On Behalf Of Aaron Wiebe
> > Sent: Donnerstag, 17. Juni 2010 14:26
> > To: rsyslog-users
> > Subject: Re: [rsyslog] feedback requested: NEW rsyslog.conf format
> >
> > <action dynfile>
> > type omfile
> >
> > Perhaps:
> > <action name=dynfile type=omfile>
> >
> > That would make something like this more readable:
> >
> > <input name=inp10515 type=imtcp><params>listen 10515; ruleset
> > remote10515</params></input>
> >
> > In other words, everything should be nameable, and everything defined
> in-
> > scope should also be reference-able.
>
> During our first discussion, we had this format approach as well. But
> we
> stayed with the apache-like approach of having only one parameter in
> the
> <input> and other blocks, and all general parameters below as
> name/value
> pairs. So everything can have a name/id besides the type. To get
> further
> verbose with the initial sample:
> <input>
> name inp10515
> type imtcp
> <params> #params holds module-specific config parameters
> listen 10514
> ruleset remote10514
> </params>
> </input>
Following Aaron's route, that would also make quite some sense:
<input
name=inp10515
type=imtcp>
listen 10514
ruleset remote10514
</input>
Note that I kept the formatting inline with the previous sample. More
compact, one could note it as:
<input name=inp10515 type=imtcp>
listen 10514
ruleset remote10514
</input>
which I have to admit I like. As we have single name/value pairs, it actually
is not a big deal if they are inside the type specifier or within the
bracketing tags. Note that by this format we could also get rid of the
<params> tag, which is a nice saving in any case.
Note to list members: I should have mentioned the difference between the
"<params>"-parameters and the others. Those in <params> are module specific,
whereas the others are generic and apply to all modules. So <params> would
actually be passed down to the module for verification. It is of advantage to
separate these two different parameter sets, even though they look pretty
much the same from an end user perspective.
Now let me make one final modification to the code sample:
<input name=inp10515 type=imtcp>
listen=10514
ruleset=remote10514
</input>
or equivalent but more compact
<input name=inp10515 type=imtcp>listen=10514 ruleset=remote10514</input>
(the last one I do *not* prefer, but that would be a user choice)
I don't see any notable disadvantage in that, but I see the advantages
outlined above.
Comments?
Rainer
_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com
