[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