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/omstdout.c;h=
e491005cca064af2c40c339af18cead9ddaf363d;hb=HEAD
The full patch is here:
http://git.adiscon.com/?p=rsyslog.git;a=commitdiff;h=ec0e2c3e7df6addc02431628
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
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/omstdout.c;h=
e491005cca064af2c40c339af18cead9ddaf363d;hb=HEAD
The full patch is here:
http://git.adiscon.com/?p=rsyslog.git;a=commitdiff;h=ec0e2c3e7df6addc02431628
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