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

[Jon Siwek]

On Mon, Feb 18, 2019 at 6:46 PM Vern Paxson <vern at corelight.com> wrote:

> Suppose "event foo(a: string)" is an event to which we want to add
> a second parameter, b: string.  We could express this in event.bif as:
>
>         event foo%(a: string%) &deprecated;
>         event foo%(a: string, b: string%);

Nice idea.  I also think that would work in this "want to add a new param" case.

> (4) avoid certain forms of user errors

Which particular user errors were a concern?

And you mean in contrast w/ my initial proposal?  I was still thinking
name-based matching most clearly expressed the users intent, so I
doubt that results in increased errors.

> and (5) allow us to consider other
> API changes such as removing parameters.

Yeah, removing should work following this scheme.  What about changing
semantics of a parameter though?  Take earlier example Vlad gave, I
think the process is:

Step 1:

    event foo%(is_server: bool%) &deprecated;
    event foo%(is_server: bool, is_client: bool%);

This is ok so far: no code will break and users can update to the new
handler with extra parameter.  It is a bit odd to have the "is_server"
parameter available for use when the actual intent is to later get rid
of it.

Step 2:

    event foo%(is_server: bool, is_client: bool%) &deprecated;
    event foo%(is_client: bool%);

Now this is really awkward: users have to update their code once again
(in my proposal, they update their code just once).

The other problem is that if a user is skipping a version, they may
end up with a handler that treats "is_server" in the original way, but
the meaning has been changed and we only match events based on type +
number of parameters.  With name-based parameter matching, we can
catch this scenario as well.

> It's not as easy to implement ... but strikes me as cleaner than where
> this discussion has wound up going.

I still prefer my original proposal from everything I've seen so far,
I think it best fit the notion of what event handlers actually are
(but maybe not how they've traditionally been thought about): we pick
points in time as an "event" and associate various bits of data with
them, then users declare their interest in some subset of that data.
Most natural way for them to do that seems to be by naming each bit of
data.

Can you maybe break down what you mean by "clean" further so we can
better compare/contrast solutions ?  I don't recall seeing anything
that was a showstopper for my original patch (but been a while).

- Jon