I agree, we're starting to get to the point of wondering why again. So here is my reason why:
My basic concern is scoping. A lot of the current format is order-specific, implicitly scoped configuration that makes it extremely hard to work with. With more explicit scoping, I'm happy. And I know this may not be a popular idea, but really, I think it should be considered -- syslog-ng's format is actually quite straightforward and easily understood. Having a format similar may be a problem for "product differentiation", but honestly, the syslog-ng method of inputs, outputs, and functions to tie those together is quite appropriate for a logging application. I'm not saying we should use their exact format, but I do like lifting some of their better config ideas. (I'm also partial to the bind-style/syslog-ng-style config format.) -Aaron On Fri, Jun 25, 2010 at 11:29 AM, <[email protected]> wrote: > On Fri, 25 Jun 2010, Rainer Gerhards wrote: > >> After all formats seem to have at least some problems attached, I decided to >> have a look at my original RainerScript idea. Note that the current (partial) >> implementation is NOT suitable for very high performance. However, that is >> something that can be changed. >> >> To understand why a language, and why a specialized one, we need to look at >> rsyslogd from a different angle: to me, rsyslogd is high performance >> processor good at shuffling messages from an input to an output and applying >> transformations while doing so. There is conditional logic involved to craft >> the path a specific message takes. >> >> So one can think of rsyslog like a specialized computer whom's instruction >> set is optimized for that purpose (I guess that is what David was referring >> to when he talked about "functions"). >> >> With that view, the configuration file is actually a programming language: >> one that specifies how to process message. Reading the config file can then >> be compared to a typical compilation, where the generated object code is >> actually targeted towards "rsyslog machine instructions". >> >> Obviously, to program that very special machine, we do need a specialized >> programming language as well. Alternatively, one may think of this language >> as being the "assembly language" of rsyslog, which closely matches the >> instruction set and thus can be used to write very efficient programs (but >> requires some skills for non-trivial cases). >> >> Having said this, all language constructs must translate natively to rsyslog >> engine objects. At the same time, they should be very simple to use for >> novice users while providing all the expressiveness an expert user needs. >> This most importantly means that the config language must be easy to read and >> edit by a human. >> [Michael: *this* actually are the requirements for the config language, >> together with the other long post this morning -- I am not sure if I find >> time to consolidate these two today.] >> >> Now please have a look at a new sample config: >> >> http://download.rsyslog.com/rainerscript_rsyslog.conf >> >> This time, I have not only included a hypothetical complex configuration, but >> also a very simple standard config - just so that we can see how verbose it >> gets. All configs are inside a single file -- you need to scroll down. >> >> All in all, I have to admit I begin to like the RainerScript approach once >> again. Unfortunately, it obviously is the solution that requires more work >> than any others (because I need to craft the grammar and the parser myself). > > after reading this I am wondering why everything needs to change. > > what concepts are missing in the current config language that you are > needing to add > > as I see it you need to add > > ability to define blocks of actions > currently this is done by changing the ruleset, this needs to be made > more explicit and obvious > > a block of actions may be a single action that's used more than once > > > ability to define if-then-else not just if-then > > combining these two to make the if-then or if-then-else do blocks of > actions. > > what else is missing? > > if you were going to a standard config language that other things could > understand then changing everything to fit that language makes sense, but > if it's going to be another custom config parser what's the benifit of > starting from scratch rather than just adding the features to the existing > one (since you will have to maintain the existing one anyway) > > David Lang > > P.S. is the rest of adiscon going to just go with XML? > > > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com > _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com
