[Zeek-Dev] support for event handlers using a subset of parameters

Vern Paxson vern at corelight.com
Fri Feb 1 10:59:01 PST 2019


> The compelling use-case I'd say is the ability to change/deprecate
> event parameters without suddenly breaking people's code since that
> has come up many times already.

I see how it allows adding new parameters.  I don't see how it helps with
deprecating existing parameters (which seems would be better served with
some sort of &deprecated attribute), and I don't see how it helps with
changing the semantics of existing event parameters.

> Also this change only effects events and hooks, not functions.  The
> semantics are different enough that maybe we would only want
> overloading for functions anyway.

It actually makes sense to me to support overloading for events.  Then for
example you could have two event signatures depending on what information
the handler was going to leverage, which would allow the event engine to
offload work if there isn't a handler for a signature that requires extra
computation.

> Hooks and events have multiple implementations/bodies that are defined
> by the *user*.  The *author* is generally the one the generates
> (calls) the event/hook.

The big exception being the event engine (if I follow what you mean by
user/author).

> So if the event/hook name were overloaded, it's a bit confusing -- the
> user now has to decide between different signatures to handle, each
> containing different data sets and maybe neither contains the set they
> want (so now they handle two events of the same name instead of one).

Not really seeing this.  I'm picturing that a common idiom will be a
lightweight version of an event and a heavyweight version, or maybe a
spectrum from light-to-heavy.

> Really, an event is a unique name with some amount of data
> (parameters) associated with it and may always be generated with the
> full data set -- the user then chooses which data they are interested
> in by defining that explicitly in the handler's parameter list.

Yeah, I agree that this too would allow (most of) the sort of offloading
I sketch above.

		Vern


More information about the zeek-dev mailing list