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
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