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