On Fri, Oct 25, 2013 at 10:52 PM, Pavel Levshin <[email protected]>wrote:
> > 25.10.2013 18:07, Rainer Gerhards: > > > My gut feeling is that we are back to Tuesday morning, and I will remove >> global variables and not introduce state vars. I really don't like >> introducing such a nondeterministic and counter-intuitive beast (global >> vars), no matter how good the use cases may look. Instead, I think I'll >> merge in mmsequence, which keeps track of the load balancing issue ... and >> will object extending it to any case that does not play well with the >> current engine (like setting and reading variables at will). read-only vars >> can be done via the lookup table system... and the rest must wait until the >> engine is ready, whenever this is. Sorry I found no better solution, but I >> need to finally table that beast. Doesn't make sense to invest even more >> time in something that sounds like very controversial. Then better use that >> towards engine enhancements in general. But, again, it's a gut feeling and >> I'll verify over the weekend. >> > > If you deside to merge mmsequence, here is latest version. > I have merged it today (unfortunately, the system clock on that system went wild for some reason, so git shows a timestamp 13 days ago...). On the overall issue: As I said, I had some discussions with my folks. The strongly discouraged me to keep the current global var functionality, for much of the same reasons that I was hesitant to do so. However, over the weekend I worked hard to get an idea of how the engine could be evolved towards "global var capability" without any hacks. It currently looks like this is possible. As my time is strictly limited at the moment, I will write down the ideas in *actual code* (writing them in natural language posts tends to take at least the same amout of time, and I have nothing to test with ;)). If someone would like to follow what's going on, keep an eye on master-ruleeng git branch. In 7.5.6, global vars will officially be no longer supported. But I "forgot" to technically disable them. So if someone has a config that relies on them, everything will continue to "work" as before. If that someone has problems, though, the answer will always be "the bug is that global vars are still recognized". As long as nobody insists on that they must work, I can keep them inside the devel version. The idea is that the new rule engine work will evolve into something that will ultimately solve the global var problem. So when 7.5 becomes 7.6 stable, the next engine version will come up as new devel version and support global vars. The stable (7.6) will NOT support them (they will also be technically removed). The idea here is that folks that really rely on them will hop from devel to next devel (skipping stable) and keep using them. My hope is that all of this works out (in decent time) and so we have a smooth migration path. For obvious reasons, non-sponsored work will focus on the engine in the next time. I also expect that we can gain quite good performance improvements from that work. 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.
