On Tue, Nov 6, 2018 at 3:00 PM Vern Paxson <v...@corelight.com> wrote:
> I think what we need to do is rethink the basic architecture/structure of > attributes. In particular, types in general (not just named types) should > be able to have attributes associated with them. The attributes associated > with an identifier are those associated with its type plus those directly > associated with the identifier (like &redef). Sounds worth pursuing. I think this was also one of the routes originally offered, but not sure if it actually got attempted or there were other complications. Hard to remember all the twists this issue has taken, but you probably have the freshest view of things at the moment to decide which way to try going. > While doing this, we can also think about mechanisms for removing attributes. > I don't think the "&attr=F" approach mentioned earlier on this thread will do > the trick, since it's syntactically/semantically quite weird for attributes > that already take expressions as values, such as &default or &read_expire. Yeah, attr removal seems to warrant its own unique syntax. But might help to just review which attrs one may actually want to remove (or even make sense to remove) -- seems like it's only &log in the first place so maybe doesn't warrant a generalized mechanism ? A related idea I haven't thought through: how about providing a BIF that does attr removal/modification? Actually seems more powerful to be able to change attributes at runtime rather than just parse-time. Another thought/worry that may or may not be valid for generalized attr remove/modification: seems there may be opportunity to create non-sensical states. e.g. the sequence of (1) create a value of the type "foo" which initially has attr &bar, (2) later remove &bar from type foo, (3) are the existing values of type foo still coherent now that they lack &bar ? Obviously made up the type/attr, but probably have to think that sequence through for each existing attribute to make sure behavior is well-defined for each. - Jon _______________________________________________ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev