On Sun, 15 Dec 2013, Pavel Levshin wrote:
15.12.2013 23:25, David Lang:
On Sun, 15 Dec 2013, Pavel Levshin wrote:
15.12.2013 23:09, David Lang:
ii) *don't even bother with the old-style config*. Double the effort,
triple the confusion. Even right now, everything supported (7.x and
later)
works with new-style config. We tell everyone to upgrade, so it makes
sense
to concentrate on the new stuff that we consider better.
sometimes it's much easier to do the old-style config, and there are a
lot of docs out there with the old style (not to mention configs), we
need people to be able to understand what these existing docs and configs
are talking about. As well as how to convert from one style to the other.
Old-style config should be obsolete, and it's a pity if they are so much
easier, that it justifies mixing them with new-style. This is not to say
that old-style should not be documented. Obviously, if they are supported,
they need to be documented. But users should feel encouraged to use just
one, hopefully newer, dialect. This can be reached by following some rules
in docs. Something like this:
- When describing a feature, use only newer syntax;
- Then list all mappings from older to newer syntax separately, with
examples, to make migration simpler.
old style configs are going to continue to be supported.
As backward compatibility measure, but their usage is not recommended, right?
So, how do we separate current syntax from legacy one?
no, old style and new style are considered equally supported, use whatever makes
the most sense for your config
*.* /var/log/messages
is FAR clearer than
action(type='omfile' file='/var/log/messages')
new features may not get old tyle config options, but the existing old
style config options need to be explained in the same place as the new
style.
I disagree. If this is done this way, an user will use any of options, not
always recommended one. Secondly, any new user is not interested in learning
old-style syntax. Therefore, it should not waste space on the same screen
where all the cool features described.
new users will need to learn the old style configs to understand the 20 years of
documentation and howto examples that exist for syslog.
in addition, very few installs are completely from scratch, they need to learn
the old style to understand the existing configs (including the configs provided
by the distros)
one of the strengths of rsyslog over syslog-ng is that it does not require users
to learn a completely new config language to keep doing what they have been
doing. Advanced stuff may require the new config language, but the existing
stuff can just be imported.
Anyone who is using old-style will need to go to a separate chapter in the
same file, and there he will see a link to the feature description above.
separate section in the same file/document is fine, but the old style config is
still fully supported.
David Lang
_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com/professional-services/
What's up with rsyslog? Follow https://twitter.com/rgerhards
NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of
sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE
THAT.
