Hi Michael, thanks for the feedback. My comments inline below.
Rainer > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:rsyslog- > [EMAIL PROTECTED] On Behalf Of Michael Biebl > Sent: Monday, February 25, 2008 3:25 PM > To: rsyslog-users > Subject: Re: [rsyslog] Some rsyslog futures and a funny thing > named"rainerscript" > > 2008/2/23, Rainer Gerhards <[EMAIL PROTECTED]>: > > Hi folks, > > > > please have a look at > > > > http://rgerhards.blogspot.com/2008/02/introducing-rainerscript-and- > some. > > html > > > > Feedback is appreciated. > > While looking at > http://www.rsyslog.com/doc-rainerscript.html > I wondered if using a complete scripting language [1] for configuraton > is not making it overly complex and error prone. I specifically means > function definition etc. here. The key is that I will model it so that the complexity is only seen when it is actually needed. Most importantly, it will continue to understand plain old syslog.conf format. So most peoply will probably never see the scripting features. HOWEVER, I think it is useful to have these for a few select folks who really need them. Function definitions, for example, will counter syslog-ng's feature to define a filter. I don't know if it is actually worth and useful to define a filter to reuse it. But with the function, you can do it. So those coming from syslog-ng can find their favorite feature ;) I think it is probably worth to think about how I came to the idea of scripting support. The root cause is complex logic, complex expressions. A few days ago I started to implement them ... and quickly found out that actually the easiest way is "to do it right". So I now have a parse, bytecode and an interpreter/virtual machine running in rsyslog. All of this "just" to support complex expressions. While I thought about it, I finally realized that it takes just a little bit to extend these things so that the end result will be an easy to use scripting facility. That also solves the config file issues that's dangeling so long and, as a side-effect, brings up some interesting options (for those that have need for it). For example, I thought about how to best handle rewriting message content. Now, the solution is obvious. I'll implement a "set" facility in the language that enables message variables to be rewritten on the fly (e.g. for folks who would like to drop some parts of the message). I agree, all not pretty mainstream, but useful in some cases. And keep in mind that it comes at a (complexity) cost only if you need it. That's based on the fact that expression support was originally planned as a by-line of the current config format, so it needed to work with the rest in any way ;) > > But if you really need that kind of flexibility and scripting > capabilites, have you considered to use existing languages, like lua > [2], which were specifically designed to be embedded into > applications? Not really, because of the way it has evolved. A know a new language is already evil, but I see big benefit for the project this time. The reason is that I can very tightly integrate it into rsyslog's features like the upcoming loader. So it will be very cleanly and efficiently integrated. For example, I don't think that I could support old-style format *just within* the new style format with any third-party engine. > Cheers, > Michael > > > [1] Not quite complete, as loop constructs are missing. The ABNF is incompelte ;) but I'll add only what can be of use for syslog and I am currently in doubt loops will be. The VM, however, would be able to handle it, it's very generically written (have a look at vm.c, has much grown today). _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog
