[Bro-Dev] [Proposal] Language extensions for better Broker support

Siwek, Jon jsiwek at illinois.edu
Wed Dec 14 09:56:10 PST 2016


> On Dec 14, 2016, at 9:27 AM, Robin Sommer <robin at icir.org> wrote:
> 
> I think that looks pretty good. But where's that Error type defined?
> Is it a new global type that Bro predefines for everybody to use? Then
> we'd either need to limit the type of errors to a small predefined
> set, or allow scripts to redef the enum and add their own types; but
> the latter risks naming clashes.

Is there risk of clashes here?  Don’t recall how intentional it is, but don’t enum redefinitions export the identifiers into the current module/namespace?  Example:

module GLOBAL;

type Error: enum {
    Success,
    InternalTimeout,
};

module Broker;

export {
    redef enum Error += {
        NotFound,
    };
}

module SomeOtherFramework;

export {
    redef enum Error += {
        WeirdError,
    };
}

module GLOBAL;

print Success;
print Broker::NotFound;
print SomeOtherFramework::WeirdError;

> Alternatively, we could leave it to frameworks to define their own
> error types. So for Broker, we'd have Broker::NotFound,
> Broker::Timeout, etc. And the opaque types would define internally
> what they convert to, and how.

So far, there's 3 pieces of information that can come out of an async function:

1) An error code that is specific to that function (e.g. Error::NotFound)
2) An error code that is not specific to that function, but comes predefined in Bro internals (e.g. Error::InternalTimeout)
3) The actual data you’d want to use in the case the function succeeds

Seems appropriate to let each framework define (1) and (3), but somehow have (2) internally predefined.  I guess the above example allows that, depending on how much you want to rely on the “redef enum” namespacing behavior?

- Jon



More information about the bro-dev mailing list