As we’re collecting initial experiences with Broker, some items for the wishlist have come up that would be nice to add. This page is collecting them (in no specific order):

• Hide the "advertise" functionality. We don’t have a good use case for that right now, leading to some confusion about the distinction between subscribing and advertizing. We’ll hardcode to auto-advertise for now and remove the option from the API (at least the Zeek API; probably also from Broker’s?)

• Extend the switch statement to dispatch based on type. That will allow to work with any types. See this mailing list post for the proposal.

• Add synchronous versions of the data store accessor functions to the Zeek API (BrokerStore::lookup, BrokerStore::keys, etc.). These would answer directly from the local cache, accepting that semantics get a bit more fuzzy that way as the cache might not yet reflect the most recent updates.

  This is a bit tricky to implement, as internally everything is asynchronous. The two options seem to be: (1) answer from the local cache through Broker/CAF, trusting that it’ll finish fast enough so that we can just wait for it; and (2) keep a separate copy of the data store in memory space that the BiF can read from directly (this would require locking that memory for reads by Zeek and updates by Broker).

• Automatically wrap/unwrap values into/out of BrokerComm::data instances. Zeek’s static typing should usually allow to do that (but not always; and/or we might need to put a few more restrictions on the types Broker handles).

  A similar wish list item applies to the Python bindings.

• Allow to associate a callback with a data store that gets triggered each time an update is received from the master. The callback’s parameters are the key that’s updated and the new value (variations are possible, too, like including the old value as well, or the specific operation being performed; but not clear how useful that would be). In Zeek, the callback would be an event, whereas at the Broker-level it could be a generic C++ function (or an actor?)

• At a data store’s master, allow to associate a hook function with the store that gets to filter all updates. Before an update takes effect, that hook function executes and may change the update (or even suppress it altogether). That allows for normalization, filtering, or syncing up with other places. In Zeek, the callback would be a script function, at the Broker-level it would be a C++ function..

• Extend Broker to support subscriptions across multiple hops, so that one can subscribe to events and data stores from any source that’s reachable through any peer. Broker needs to learn keeping track who has subscribed to what so that it can forward information accordingly. As an extension, we can also add an option to allow peers to connect directly on demand; CAF supports that already.

• Handle sending Zeek’s opaque types transparently by serializating them into strings before passing to Broker. Only Zeek will be able to operate on them that way, but the alternative of adding direct support to Broker for each opaque type seems overly complex.