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? 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) 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. David Lang _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com
