On Fri, Jan 31, 2014 at 6:50 AM, Nathan Brown <[email protected]> wrote:
> Fully agree that some plugins will be brain dead simple and will only > require an incredibly small feature set of what the plugin system may > offer. But having multiple communications options, certainly ones that > are entirely unstructured, will be difficult to maintain. Forward > compatibility of a plugin that may start simple but eventually will > want to grow into something more complex is a good enough reason to > have a structured plugin protocol. Let alone rsyslog's side that may > increase the feature set that it can offer a plugin. JSON has proven > it's a good candidate for this sort of thing, lightweight with decent > native types. > > IMO rsyslog is still about speed, even though we sacrifice it for the sake of making it easy to write plugins. I agree that JSON is the most versatile format and something to recommend for the general case. HOWEVER, there is quite a bit of overhead associated with crafting an all-JSON representation of a message object. So I think we should not FORCE plugins to use JSON format. There are many cases where this makes sense, but there are also many cases where simply -and much faster!- formats make more sense. Given the simplicity of the interface, I think anyone should understand what he is doing. Even more so, for real novices, getting the JSON parser to work might be a stumbling stone, whereas pulling pre-formatted data from stdin makes them happy. This is why I think we should not enforce the use of JSON on the interface. Rainer > > On Jan 30, 2014, at 9:11 PM, David Lang <[email protected]> wrote: > > > > The thing is that with the rsyslog templates, you can do a lot of > formatting and manipulation of the data before you send it to the module. > so you should configure rsyslog to send your module whatever it can handle > the best. > > > > If you have typical needs (take this entire line and send it there) you > can get by with a very simple output module. If you have very complex > needs, you may need to use JSON to structure things so that it's always > clear what's what. > > > > the author of the output module needs to document what that module > requires as it's input. > > > > overall this looks pretty good. > > > > David Lang > > > >> On Wed, 29 Jan 2014, Nathan Brown wrote: > >> > >> I would avoid having multiple communication options and use only line > >> delimited JSON to talk between the plugin and rsyslog. > >> > >> > >> On Wed, Jan 29, 2014 at 3:21 AM, Rainer Gerhards > >> <[email protected]>wrote: > >> > >>> Hi all, > >>> > >>> I've written a short presentation on writing rsyslog output plugins. > It is > >>> targeted towards people who would like to know at least a bit about how > >>> this works. I also plan to do an ultra-fasttrack document for those > that > >>> just want to get it going somehow and don't about how it works. They > are > >>> *not* the focus of the current presentation: > >>> > >>> http://www.slideshare.net/rainergerhards1/external-plugins > >>> > >>> I will include this information in the Fedora DevConf Talk next week, > and > >>> would really like your feedback. Where can we improve it, how to make > even > >>> more clear that it's simple. Note that I say "v8" only because it > already > >>> covers a bit of what we will have in a month or so (the stdout > feedback). > >>> When I give the presentation, I'll tell that omprog in older versions > works > >>> mostly the same. > >>> > >>> Thanks, > >>> Rainer > >>> _______________________________________________ > >>> 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. > >> _______________________________________________ > >> 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. > > _______________________________________________ > > 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. > _______________________________________________ > 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. > _______________________________________________ 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.
