I have now also created at least a bit of developer documentation:
http://www.rsyslog.com/doc-dev_oplugins.html
Rainer
> -----Original Message-----
> From: rsyslog-bounces@lists.adiscon.com [mailto:rsyslog-
> bounces@lists.adiscon.com] On Behalf Of Rainer Gerhards
> Sent: Friday, April 03, 2009 2:19 PM
> To: rsyslog-users
> Subject: Re: [rsyslog] RFC: On
> rsyslogoutputmodulesandsupportforbatchoperations
>
> I have worked on the new interface this morning. As always, there were
> a
> couple of subtleties, but I now have applied the patch to the current
> master.
> Now, an output plugin can receive the template in two ways: either as a
> string (the current way of doing things) or as an array of string
> pointers.
> This is transparent to the end user.
>
> I have not yet created documentation on how to use it, but I have used
> omstdout during my testing and it shows very well how to work with the
> new
> method. It also shows all the necessary plumbing to be compatible both
> with
> current and previous rsyslogd version (if that is of interest for
> someone).
> You can find it via gitweb:
>
> http://git.adiscon.com/?p=rsyslog.git;a=blob;f=plugins/omstdout/omstdou
> t.c;h=
> e491005cca064af2c40c339af18cead9ddaf363d;hb=HEAD
>
>
> The full patch is here:
>
> http://git.adiscon.com/?p=rsyslog.git;a=commitdiff;h=ec0e2c3e7df6addc02
> 431628
> daddfeae49b92af7
>
> I will release it as part of the upcoming 4.1.6 devel, due next week.
>
> I hope this is a useful addition. Feedback is appreciated.
>
> Rainer
>
> > -----Original Message-----
> > From: rsyslog-bounces@lists.adiscon.com [mailto:rsyslog-
> > bounces@lists.adiscon.com] On Behalf Of Rainer Gerhards
> > Sent: Thursday, April 02, 2009 7:00 PM
> > To: rsyslog-users
> > Subject: Re: [rsyslog] RFC: On rsyslog
> > outputmodulesandsupportforbatchoperations
> >
> > It is probably clean that we simply define a new public entry point
> > inside
> > the rsyslog core that old versions do not have. The output plugin
> > simply uses
> > it. If it is tried to be loaded on old rsyslogd, the entry point is
> not
> > found
> > and the loader refuses to load the module. It is somewhat ugly in
> that
> > the
> > error message may be misleading (doc can solve that), but otherwise I
> > think
> > it works perfectly well - after all, the only thing we could do is
> > disable
> > the module on versions that do not support the functionality. That
> just
> > disables the ability to use an alternate implementation in case of
> the
> > one
> > not available... well.. we can do it that way via an internal API,
> too,
> > if I
> > think correctly. OK, a solution begins to form ;)
> >
> > Rainer
> >
> > > -----Original Message-----
> > > From: rsyslog-bounces@lists.adiscon.com [mailto:rsyslog-
> > > bounces@lists.adiscon.com] On Behalf Of Rainer Gerhards
> > > Sent: Thursday, April 02, 2009 6:45 PM
> > > To: rsyslog-users
> > > Subject: Re: [rsyslog] RFC: On rsyslog output
> > > modulesandsupportforbatchoperations
> > >
> > > > > For instance, if I specify:
> > > > >
> > > > > %fromhost%,%timestamp:::date-rfc3339%,%msg%
> > > > >
> > > > > Can I have an array of pointers to each already processed
> > property?
> > > >
> > > > I will investigate that. It just occured to me that I have the
> > > template
> > > > compiled as a linked list. It should not be too much of an effort
> > to
> > > > turn
> > > > values into a linked list rather than a string. Will check, but
> no
> > > > promise.
> > >
> > > That was a good discussion result. I think it is trivial to
> generate
> > > such a
> > > linked list. However, it is not as trivial (but I think simple
> > enough)
> > > to
> > > extend the plugin interface so that a plugin may request the linked
> > > list
> > > instead of the string. In order to preserve interfaces, I'll
> probably
> > > need to
> > > abuse the ppStrings[] array, so that in the linkedList case a cast
> is
> > > necessary. But I think this is clean enough. We just need to ensure
> > > that the
> > > plugin does not abort an older rsyslogd and an older rsyslogd does
> > not
> > > abort
> > > the plugin ;) A lot of chore is on the plugin, I think, in checking
> > > that
> > > everything is actually available...
> > >
> > > >From the user's perspective, the same template syntax is used, no
> > > matter how
> > > it is passed to the plugin. This can be considered nice (but some
> may
> > > not
> > > like it ;)).
> > >
> > > Will try to dig deeper into this.
> > >
> > > Rainer
> > > _______________________________________________
> > > 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
> _______________________________________________
> 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
http://www.rsyslog.com/doc-dev_oplugins.html
Rainer
> -----Original Message-----
> From: rsyslog-bounces@lists.adiscon.com [mailto:rsyslog-
> bounces@lists.adiscon.com] On Behalf Of Rainer Gerhards
> Sent: Friday, April 03, 2009 2:19 PM
> To: rsyslog-users
> Subject: Re: [rsyslog] RFC: On
> rsyslogoutputmodulesandsupportforbatchoperations
>
> I have worked on the new interface this morning. As always, there were
> a
> couple of subtleties, but I now have applied the patch to the current
> master.
> Now, an output plugin can receive the template in two ways: either as a
> string (the current way of doing things) or as an array of string
> pointers.
> This is transparent to the end user.
>
> I have not yet created documentation on how to use it, but I have used
> omstdout during my testing and it shows very well how to work with the
> new
> method. It also shows all the necessary plumbing to be compatible both
> with
> current and previous rsyslogd version (if that is of interest for
> someone).
> You can find it via gitweb:
>
> http://git.adiscon.com/?p=rsyslog.git;a=blob;f=plugins/omstdout/omstdou
> t.c;h=
> e491005cca064af2c40c339af18cead9ddaf363d;hb=HEAD
>
>
> The full patch is here:
>
> http://git.adiscon.com/?p=rsyslog.git;a=commitdiff;h=ec0e2c3e7df6addc02
> 431628
> daddfeae49b92af7
>
> I will release it as part of the upcoming 4.1.6 devel, due next week.
>
> I hope this is a useful addition. Feedback is appreciated.
>
> Rainer
>
> > -----Original Message-----
> > From: rsyslog-bounces@lists.adiscon.com [mailto:rsyslog-
> > bounces@lists.adiscon.com] On Behalf Of Rainer Gerhards
> > Sent: Thursday, April 02, 2009 7:00 PM
> > To: rsyslog-users
> > Subject: Re: [rsyslog] RFC: On rsyslog
> > outputmodulesandsupportforbatchoperations
> >
> > It is probably clean that we simply define a new public entry point
> > inside
> > the rsyslog core that old versions do not have. The output plugin
> > simply uses
> > it. If it is tried to be loaded on old rsyslogd, the entry point is
> not
> > found
> > and the loader refuses to load the module. It is somewhat ugly in
> that
> > the
> > error message may be misleading (doc can solve that), but otherwise I
> > think
> > it works perfectly well - after all, the only thing we could do is
> > disable
> > the module on versions that do not support the functionality. That
> just
> > disables the ability to use an alternate implementation in case of
> the
> > one
> > not available... well.. we can do it that way via an internal API,
> too,
> > if I
> > think correctly. OK, a solution begins to form ;)
> >
> > Rainer
> >
> > > -----Original Message-----
> > > From: rsyslog-bounces@lists.adiscon.com [mailto:rsyslog-
> > > bounces@lists.adiscon.com] On Behalf Of Rainer Gerhards
> > > Sent: Thursday, April 02, 2009 6:45 PM
> > > To: rsyslog-users
> > > Subject: Re: [rsyslog] RFC: On rsyslog output
> > > modulesandsupportforbatchoperations
> > >
> > > > > For instance, if I specify:
> > > > >
> > > > > %fromhost%,%timestamp:::date-rfc3339%,%msg%
> > > > >
> > > > > Can I have an array of pointers to each already processed
> > property?
> > > >
> > > > I will investigate that. It just occured to me that I have the
> > > template
> > > > compiled as a linked list. It should not be too much of an effort
> > to
> > > > turn
> > > > values into a linked list rather than a string. Will check, but
> no
> > > > promise.
> > >
> > > That was a good discussion result. I think it is trivial to
> generate
> > > such a
> > > linked list. However, it is not as trivial (but I think simple
> > enough)
> > > to
> > > extend the plugin interface so that a plugin may request the linked
> > > list
> > > instead of the string. In order to preserve interfaces, I'll
> probably
> > > need to
> > > abuse the ppStrings[] array, so that in the linkedList case a cast
> is
> > > necessary. But I think this is clean enough. We just need to ensure
> > > that the
> > > plugin does not abort an older rsyslogd and an older rsyslogd does
> > not
> > > abort
> > > the plugin ;) A lot of chore is on the plugin, I think, in checking
> > > that
> > > everything is actually available...
> > >
> > > >From the user's perspective, the same template syntax is used, no
> > > matter how
> > > it is passed to the plugin. This can be considered nice (but some
> may
> > > not
> > > like it ;)).
> > >
> > > Will try to dig deeper into this.
> > >
> > > Rainer
> > > _______________________________________________
> > > 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
> _______________________________________________
> 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