On Fri, Oct 25, 2013 at 11:40 AM, Rainer Gerhards <[email protected]>wrote:
> On Fri, Oct 25, 2013 at 10:42 AM, David Lang <[email protected]> wrote: > >> On Fri, 25 Oct 2013, Rainer Gerhards wrote: >> >> Hi all, >>> >>> I thought out the details of what I have on my mind and think the >>> solution >>> can work and support all known use cases. I've also managed to write it >>> down this morning: >>> >>> http://blog.gerhards.net/2013/**10/a-proposal-for-rsyslog-** >>> state-variables.html<http://blog.gerhards.net/2013/10/a-proposal-for-rsyslog-state-variables.html> >>> >>> I would appreciate if you could check it and see how the spec can be >>> technically broken or identify use cases which it will not be able to >>> handle. >>> >> >> >> One case I don't think it can handle is the current work that mmcount is >> doing. >> >> I have now reviewed what it is doing, including the sample conf that came with the patch. > As I understand mmcount, it creates a counter for each appname that it >> sees, and uses that to count how many times that appname has been seen. >> >> yes, but it does more. It keeps these counts internally and just returns a single variable that matches the *current* count. So it is a very specific solution, not something that you can mimic with a generic state (or global) variable system easily - requires support logic or further indirection capabilities. > the fact that you can use $/a!b lets you have the variables without having >> the conflict with anything else, >> >> but you end up with no way to know what variables exist >> >> you can't output the entire set of counts without being able to use $/a >> >> you can't even lookup the count for the current message's appname without >> being able to use domething like $a/{$appname} >> >> > you are right, that use case breaks. Thanks! I'll review mmcount in more > depth now and see how it is actually used. > > So I don't think this is one of the "usual" use cases, but instead a highly complex one which would require custom logic even if global variables had worked the way you'd usually expect. In other words: no show stopper. > The ability to support subtrees can be added, but will be relatively > expensive. > > Do we actually need subtree access? Rainer _______________________________________________ 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.
