> -----Original Message----- > From: [email protected] [mailto:rsyslog- > [email protected]] On Behalf Of [email protected] > Sent: Monday, April 20, 2009 7:24 PM > To: rsyslog-users > Subject: Re: [rsyslog] RFC: On rsyslog output modules and support > forbatchoperations > > On Mon, 20 Apr 2009, Rainer Gerhards wrote: > > >> -----Original Message----- > >> From: [email protected] [mailto:rsyslog- > >> [email protected]] On Behalf Of [email protected] > >> > >> On Mon, 20 Apr 2009, Rainer Gerhards wrote: > >> > >>> I just realize I never sent this thought... > >>> > >>>> -----Original Message----- > >>>> From: [email protected] [mailto:rsyslog- > >>>> [email protected]] On Behalf Of Luis Fernando Mu?oz Mej?as > >>>> Sent: Friday, April 17, 2009 5:13 PM > >>>> To: rsyslog-users > >>>> Subject: Re: [rsyslog] RFC: On rsyslog output modules and support > >>>> forbatchoperations > >>> > >>> > >>>>> For the case given above, I could still simply pass in a single - > >> now > >>>>> longer - string (that makes it that attractive for the other db > >>>>> plugins). However, that does not work for the omoracle interface. > >>>> > >>>> For omoracle it's not good, indeed. Also, I don't think you want > to > >>>> maintain yet another way of passing messages to modules. IMHO, we > >> have > >>>> two orthogonal use cases: > >>>> > >>>> a) the module wants all messages one by one and is happy with it > >> (all > >>>> modules but omoracle). > >>>> > >>>> b) the module wants to handle the properties in big batches > >> (omoracle). > >>>> > >>>> IMHO, this is flexible enough for new developers to choose between > >> easy > >>>> and fast. > >>> > >>> Plus there is the question of compatibility. I don't like to change > >> an > >>> interface once it is introduced. Granted, we have a small time > frame > >> now > >>> where we can model the new "vector interface" - because so far it > is > >> in devel > >>> only (and thus should not be considered immutable) and you are > >> probably the > >>> only user. But on the other hand, having two different modes may > also > >> make > >>> sense: > >>> > >>> a) string IF, single entry > >>> b) string IF, multiple entry > >>> c) vector interface, single vector > >>> d) vector interface, multiple vectors > >>> > >>> If I'd start from scratch, a+c would obviously not be needed, as > >> multiple > >>> includes n=1 (if well-crafte). But case a) is already in wide- > spread > >> use, no > >>> chance to undo that. b) would definitely be useful (just think > about > >> the file > >>> writer or TCP forwarding). So it probably is nice to have two > >> options, well > >>> and consistent defined, rather than a set of three values that map > >> {a,b,d}. > >>> At least this is my current school of thought... > >> > >> are there any known external output modules for rsyslog? > > > > At least one, at Frankfurt stock exchange (as of forum posts), > probably at > > least another one. I'd say there is sufficient probability we need to > think > > abot compatibility. > > > >> > >> if not it may make sense to do a+c (or a+d) with a being depriciated > >> (not > >> used for anything new, replaced where in use as time allows) > > > > We could do that, but it doesn?t change that much in the next 10 > years... > > > >> > >> while b could be useful, I think it's probably simpler to define > either > >> c > >> or d and have everything use that than to define an additional > >> interface. > > > > But that complicates outputs, the file writer will definitely want b > - why > > force it to work on arrays and combine all the string itself? > > if it allows you to eliminate an entire class of interface, that may be > worth it. something needs to combine the strings, and (not knowing the > code intimatly) I don't see a huge difference between doing it in one > place vs the other.
It's code reuse - why make each output plugin that potentially could use this implement it on its own. Also note that it is "*one* place vs. potentially *many* others." Also, it is a performance issue - if we have this interface, the core can generate one big string and everything is done. If we do not have it, the core needs to generate an argument array first and then the plugin must convert that array into a string. I'd say that both operations are roughly equally costly, so you save half of the cost by supporting that "big string type" of interface. Finally, you need to keep in mind that it is very easy to do that kind of interface handling inside the core - I already do it for the vector interface. In general, the interface provides a pointer. What this pointer intends to mean is modified by a function call. See omstdout for an example, it is my test driver that implements a hybrid interface support: http://git.adiscon.com/?p=rsyslog.git;a=blob;f=plugins/omstdout/omstdout.c;h= 181895a418dbbe01ac1d65dbac60fd159535e8fa;hb=refs/heads/nextmaster#l94 Line 94ff is the actual consumer and in line 143 it tells the rsyslog core what format it wants. Extending this by one more bit is really not a big deal (but, granted, this is an architecture question). [line 181 to 191 check which modes are supported]. _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com
