[Bro-Dev] changing Notice::policy mechanism

[Robin Sommer]

Can't say I like the multi-body functions; it's an unusual concept and
they'd come with untuitive limitations (like the no return value
constraint). Or put differently, I believe what you call multi-body
functions here are actually just the synchronous events you proposed
first. :-)

Let me try to structure this a bit. The current policy approach gives
us four things I believe (let me know if I'm missing something):

    (1) Immediate execution to completion (that's the synchronous).

    (2) The ability for an item to prevent others from being considered.

    (3) Returning values back to the code running executing the policy
        (actions, suppress_for, etc.)

    (4) Items sorted by priority.

Events currently only provide (4), but I can see changing them to
do (1) and (2):

    - (1): That's the "synchronous" part. There's actually nothing
    internally that would prevent us from executing event handlers
    immediately, rather than queuing them first. In some sense, they
    would jump to the head of the queue and be processed immediately.
    We could indeed introduce a new attribute for such events, though
    I'm not sure I like &synchronous (but no better idea right now).

    This would vioalate the current FIFO order of events, but with
    explicit marking, I think that'd be ok.

    - (2): Jon suggested a boolean flag but I don't like that because
    now each handler would need check for it, which is easy to forget
    and generally repetetive. Another idea for this has been floating
    around already: allow event handlers to stop execution of further
    handlers of the same kind for an event. Something like:

        event foo()
        {
           [...]
           event stop; # No further handlers for this event.
        }


(3) is tricky though, not sure how to do that without return values?
Question is: can we do without? We don't need it for actions (they can
just turn into function calls), but what about suppress-for style
stuff. Seth, you said that suppress_for is not a problem either?

Robin


-- 
Robin Sommer * Phone +1 (510) 722-6541 * robin at icir.org
ICSI/LBNL    * Fax   +1 (510) 666-2956 *   www.icir.org