Not sure, is Broker::auto_publish() currently able to do the same thing?
Hmm .. Good point. Scope is different between the two (event vs topic)
but the effect is similar in the end.
I can also see the opposite being intuitive: If I told
Broker::subscribe() to raise locally, then I get just always use
Broker::publish() and not think about the difference between using
"event" versus "publish". Would Broker::auto_publish() be removable
then?
I would like to say "yes" (because I like the subscribe() approach
better than auto_publish() :-), but would that work well with our
cluster topics? If we didn't have the event-specific auto_publish(),
we would have to turn on local raise for *all* events going to, e.g.,
bro/cluster/worker. And thinking about it, maybe that's in fact also
an argument against my original thinking how this could help unify
scripts --- well, unless we'd go with Jan's thought of subtopics
(e.g., subscribe("bro/cluster/worker/intel", local_raise=T).
That doesn't look like an API simplification to me ;D
Even Newer Worker:
Broker::publish(Cluster::worker_topic, my_event);
See any problems there?
For this case: Would it be easy to setup distinct pools for different tasks? I could imagine a pool of proxies that is used explicitly for intel distribution and one pool used for processing SumStats events. I think we have discussed something like that before. Maybe I am mixing cluster and broker levels again...
> Old Worker:
>
> Cluster::relay_rr(Cluster::proxy_pool, my_event);
>
> New Worker:
>
> Broker::publish(Cluster::rr_topic(Cluster::proxy_pool), my_event);
That doesn't look like an API simplification to me ;D
The goal here I imagine is rather to avoid releasing a function that
we knowingly plan to remove later. A user would have to eventually
port all Cluster::relay_rr() calls, but that Broker::publish() pattern
remains valid.
> Even Newer Worker:
>
> Broker::publish(Cluster::worker_topic, my_event);
>
> See any problems there?
For this case: Would it be easy to setup distinct pools for different
tasks? I could imagine a pool of proxies that is used explicitly for
intel distribution and one pool used for processing SumStats events. I
think we have discussed something like that before.
Yeah, it would still be possible to define your own pool and use it
for your own purposes and it looks similar to the call before:
A difference in the context of our needs for the cluster communication
is that the pool is being used as a means of achieving routing (in a
load-balanced fashion) and so the call gets simplified once those
mechanisms get built into Broker routing. In your case, you don't
need the routing aspect, just the load-balancing provided by the
"pool" concept.