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
