[syslog-ng] [announce] patterndb project

[Balazs Scheidler]

On Thu, 2010-07-01 at 17:35 -0500, Martin Holste wrote:
> I've read through them and I think they're definitely on the right
> track.  One thing that might be good to consider would be a way to
> store hierarchical information.  For example, the secevt class in the
> schema doc is really a network class as it only requires the network
> tuple.  So, you could have a hierarchy like this:
> 
> class Net { required_fields: [ proto, srcip, dstip, srcport, dstport
> ], optional_fields: [ in_iface, out_iface, details ] }
> class NAT { required_fields: [ nat_srcip, nat_dstip, nat_srcport,
> nat_dstport ] }
> class Security { required_fields: [ verdict ], optional_fields: [ zone ] }
> 
> This implies that the class Net.NAT.Security requires proto, srcip,
> dstip, srcport, dstport, nat_srcip, nat_dstip, nat_srcport,
> nat_dstport, and verdict, but Net.Security only requires proto, srcip,
> dstip, srcport, dstport, and verdict.
> 
> By that token, there's no difference between Security.NAT.Net and
> Net.NAT.Security, so these are really more like tags than a hierarchy.

Hmm.. interesting idea, making a hierarchy of schemas. Again some more
food for thought.

Is there a reason you want this behaviour implied, rather than being
explicit? Maybe using a different syntax would make that more obvious.
When combining schemas then instead of using '.' as a separator, use '+'

Net+NAT+Security

This would make it obvious that you can write the schema names in any 
order (since this is true for the mathematical '+' sign everyone knows).

Also, how would you represent this in a pattern? Right now you can 
assign multiple tags and any number of name-value pairs. Combining these 
in the way you described would only be needed in case someone wants to 
use the same SQL/CSV table with the nonexisting columns skipped. Or?

-- 
Bazsi