On Tue, Oct 22, 2013 at 1:30 PM, David Lang <[email protected]> wrote:
> 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 $.
>
>
The important thing is the message context.
> 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.
>
>
... below ...
>
> 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
>
NO! the problem is not the name space, but that you cannot obtain the
"right" value for the message you are processing. So it MUST be stored in
the *message context*. That's the root (and actually only! -- but severe)
problem.
Let me think a bit about a syntax:
set $.localvar=global("set", "keyname", expr);
In global(), expr can be arbitrarily complex. The first parameter could
also be "add", "subtract" ... or whatever (you get the idea). Of course,
first, and second parameter could also be expressions.
The function would maintain an internal static state and expose it only via
its opeation and the return value.
then you can query $.localvar, which always will have the correct value
*for each message*:
if $.localvar % 3 == 0 then ...
well, thinking about it, you could also do
if global("add", "keyname", 1) % 3 == 0 then...
BUT that would fail... just like global variables do (and for the same
reason) -- at least I think so, need to think this out... (it may work, as
the if is evaluated in message context, IIRC -- but need to verify).
Actually... sound pretty good now that I have written it down ;)
Rainer
>
>
> 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://lists.adiscon.net/mailman/listinfo/rsyslog>
> http://www.rsyslog.com/**professional-services/<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.
