[Bro-Dev] Broker::publish API

[Jon Siwek]

On Fri, Jul 27, 2018 at 7:30 PM Azoff, Justin S <jazoff at illinois.edu> wrote:
>
>
> > On Jul 27, 2018, at 6:10 PM, Jon Siwek <jsiwek at corelight.com> wrote:
> >
> > On Fri, Jul 27, 2018 at 3:55 PM Azoff, Justin S <jazoff at illinois.edu> wrote:
> >
> >> I do agree that there's room for a lot of simplification, for example a worker broadcasting a message efficiently to all
> >> other workers needs to do something like this from the docs:
> >>
> >>        Cluster::relay_rr(Cluster::proxy_pool, "example_key",
> >>                          Cluster::worker_topic, worker_to_workers,
> >>                          Cluster::node + " (via a proxy)");
> >>
> >> But a lot of that could have defaults:
> >>
> >> Most use cases would want to relay through the default proxy pool
> >> Since round robin is in use, they key shouldn't matter.
> >
> > At the moment, one could write their own wrapper function around that
> > if they find it too verbose and always want to use certain defaults?
>
> Yeah.. The wrapper would be trivial.. Should bro include it so that the API scripts use is simpler?

Maybe.  We can see how it fits in the mix of what Robin suggested:

  # Supports variadic args in place of Broker::Event.
  Broker::publish(topic: string, args: Broker::Event, relay_topic:
string &default="", process_on_relayer: bool &default=F)

  # Supports variadic args in place of Broker::Event.
  Cluster::publish(pool: Cluster::pool, key: any, strategy: enum,
args: Broker::Event, relay_topic: string &default="",
process_on_relayer: bool &default=F)

  # Supports variadic args in place of Broker::Event.  Use proxy pool
and RR method w/ arbitrary, internal key by default.
  Cluster::publish_via_proxy(relay_topic: string, args: Broker::Event)

That last one being the wrapper you're asking for.  Also, I compressed
the ideas of having a separate "relay: bool" / "relay_hops: int" and
"relay_topic: string" args -- a non-empty relay topic implicitly means
you want to enable relaying on the receiving node.  Thinking more
about original idea of giving the number of relay hops: it may be
better to leave that until Broker multihop is more robust and allow
it's automatic forwarding mechanisms to take care of those scenarios
whereas a "relay" is a simple mechanism at the Bro application level
(has it's own unique message format) that serves to aid load-balancing
use-cases (rather than routing use-cases).

- Jon