On Thu, Sep 26, 2013 at 6:14 PM, David Lang <[email protected]> wrote: > On Thu, 26 Sep 2013, Rainer Gerhards wrote: > > On Tue, Sep 24, 2013 at 8:00 PM, David Lang <[email protected]> wrote: >> >> Rainer, is there an example of a simple module being converted to the new >>> config syntax? >>> >>> I'm thinking that it would be useful to start collecting examples of >>> commits that do fairly simple things as documentation for programmers >>> trying to create/improve modules >>> >>> a few of simple ones to start off with: >>> >>> 1. add a config parameter (I think I can dig this up from the imfile >>> changes where we implemented the multi-line mode) >>> >>> >> I'll see if I can dig out something. But usually, there is more in a >> single >> commit - because new params get added for new functionality and so this is >> always intermixed. >> > > If we can pick something that adds fairly trivial functionality, that > would be a good example.
Have you seen my other message with omfile? > > > >>> 2. change a new style parameter >>> >>> I'm looking at omruleset and it looks like it may not support the new >>> config format yet, but I'm not sure. If it does, I'd like to understand >>> how >>> it does, if not, it looks like it would be a tiny change and a good >>> example >>> case >>> >>> >> Actually not, because this is a deprecated module, carried within the >> source tree just for backward compatibility. The "call" statement can do >> anything omruleset does, but in a much higher performance way. >> >> But I think ommail is also missing the new style config. I'll check and, >> if >> so, it would make sense to convert it. When doing so, I could do baby-step >> commits that show things being done individually. >> > > Ok, I'm not easily finding documentation on 'call' (it's too common a > word), pointer please oops... I thought it migrated into the official doc, but doesn't look so. Here is the relevant blog entry: http://blog.gerhards.net/2012/10/how-to-use-rsyslogs-ruleset-and-call.html > > > >>> 3. how to manipulate the raw message buffer in parsing modules (I have >>> this archived in e-mail, I'll dig it up) >>> >>> >>> That's somewhat tricky at the moment and not properly encapsulated. >> Important question: do you really mean rawmsg or just the msg part of the >> message (rawmsg is even tricker due to the low-level optimizations made). >> > > I was talking about rawmsg, the type of changes that I was doing in the > cleanup type parser modules (that tweak the incoming file to make it sane > before letting it fall through to a 'normal' parser) > I still don't believe in that approach ;) As you've seen, I've modelled all new parsiong modules via the action interface. Doesn't mean I am totally opposing it. One caveat is that there currently is no new-style interface for parser modules (again, not opposing this, but definitely not high priority work). > > > What I'm hoping to generate here is a document that can become a 'getting > started hacking rsyslgo' guide that will show the right way to do some of > these things. > > There is the template module code, which is a good start, but as I've > learned the hard way, adding functionality requires hooks elsewhere in the > code, and I'm thinking that the easiest way to document some of these > things is just to point to commits in git that add the right thing. > > > so when adding new optional functionality, you need to > > 1. implement the functionality > > 2. add the old-style parameter for it > nope, you shouldn't add new legacy parameters. > > 3. add the new-style parameter for it > > 4. add the documentation for it > > 5. add a test for it > > I don't think any of my contributions have gotten all of these right (or > even all except the new style parameters) > > I begun to do this with my omfile change today. All in all, I agree. Rainer > > David Lang > ______________________________**_________________ > rsyslog mailing list > http://lists.adiscon.net/**mailman/listinfo/rsyslog<http://lists.adiscon.net/mailman/listinfo/rsyslog> > http://www.rsyslog.com/**professional-services/<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. > _______________________________________________ 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.

