On Tue, 22 Oct 2013, Rainer Gerhards wrote:
On Tue, Oct 22, 2013 at 1:09 PM, David Lang <[email protected]> wrote:
well, I wouldn't want to have the module store a counter into the $!
namespace, too much chance of conflicting with something from a message,
and if I've got several things stored (for different purposes), I don't
want them to all show up when I output $!
let the user decided. For this, we have local vars.
Ok, I thought you were saying that they would go into $!, not $.
as you show below, doing this for an explicit save is very stratightforward
(although why do you need both key and store_to? I would think either would be
enough to specify the variable name to use)
but for counting and sequences, especially for ones that count separately based
on a message property (such as appname), this seems harder.
although I guess when you are setting up the counter, you can specify a base
variable, and allow the module to create subvariables from there.
store it in $. or in some different namespace (say $/ ;-p )
for counting and sequence numbers this sounds reasonable.
but what are you thinking about for storing other values? I'm expecthing
that most of these other values will be strings.
What's the difference?
e.g. (just psedudocode)
action(type="globals" key="mykey" value="some string" store_to=".localvar")
it may be useful to implement this as function rather than action or even a
totally new object -- makes integrating with expressions much easier (for
outputs, you must always go through a template).
I think a function would be better, doing it as an action brings along a lot of
baggage to confuse people (separate queues for example)
But the 7.5.4 globals vars cannot do this, as you cannot attach semantics
to them that *force* to write to a local var -- this is the root problem.
well, since they were in a different namespace entirely, they didn't need to
write to a local var
One other issue that this does create is that there are now two classes of
message modification modules
1. modules that could have multiple copies running, needing only to coordinate
enough to not be modifying the same message
2. modules that are doing things across messages, so multiple copies get really
messy
I'm not sure that this is really a whole lot better, but I guess it's taking it
away from directly being exposed to the users, so less potential for confusion.
David Lang
_______________________________________________
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.
