On Fri, 2010-09-03 at 12:24 -0700, Matthew Hall wrote:
On Fri, Sep 03, 2010 at 09:11:59PM +0200, Balazs Scheidler wrote:
Hi,
Hey Bazsi,
So one email, two questions, feedback appreciated.
Not sure if it's an option but the idea which occurs to me is that you are looking for a way of setting and optionally mapping some keys like ".classifier.class" or "mhall_special_tag" to some value like "{ violation, security, ... }".
So my suggestion would be to remap the ".classifier.class" into the tag system for compatibility, then extend the tag system to be a hash table.
The nice thing about the hash table would be, you could still support existing tags. For example if I tagged a message as "mhall_special_tag", in the hash table you could map that:
mhall_special_tag -> PLACEHOLDER
Then for fancier tags like ".classifier.class" you could map that:
.classifier.class -> { violation, security, ... }
Then you could provide some kind of utilities for it to expand what you need.
1) an operation to check if a key is set 2) an operation to get the value set for some key 3) an operation to check if a value is set 4) etc...
Then when I want to break out messages to classifier based dirs, I could just call operation (2) to get the value of ".classifier.class".
If I wanted to make a filter that grabbed messages with mhall_special_tag set, I could do that using operation (1).
Hmm.. the message itself is already a hashtable (not exactly, but semantically they are the same). What you say with the above is that tags should be present/non-present attributes of the message, right? The problem I see with this is the namespace, I wouldn't want to collide tag names with built-in macros or name-value pairs. -- Bazsi