I'm considering renaming the C++ broker namespace from "broker" to
"bro". After all, it's *Bro's* communication library. This would reduce
noise in the source code (3 less characters for those who cannot or
don't want to import the entire namespace) and also reduce ambiguity (we
can now use bro::broker as a class name). The only point where I could
see this problematic is if we ever wanted to distribute Bro itself as
shared library. Personally, I don't see this a realistic outcome though.
The overwhelming amount of global state and program structure has not
been designed to allow for distribution as (shared) library.
I'm considering renaming the C++ broker namespace from "broker" to
"bro". After all, it's *Bro's* communication library.
Not sure I like that. The library is called Broker, so "broker" seems
the natural namespace to me. And it's not really just for Bro either,
people might just as well use it outside of Bro (and I hope they
eventually will!
This would reduce noise in the source code (3 less characters for
those who cannot or don't want to import the entire namespace) and
also reduce ambiguity (we can now use bro::broker as a class name).
I don't think the first one is a problem, and the latter is a
self-made one: I think the better solution would be finding a
different name for those things now called "broker", rather than
changing the entire namespace.
Not sure I like that. The library is called Broker, so "broker" seems
the natural namespace to me.
All right, let's keep it as is. This is also aligns with the sentiment
at our Gitter room.
I think the better solution would be finding a different name for
those things now called "broker" [..]
Speaking of which: let me summarize the issue. We need a good name for
something that is a message broker, an entity that communicates in the
publish/subscribe paradigm. These message brokers can communicate via
TCP or shared memory, and any program can have a large number of them.
In the current Broker code, we use the term "endpoint," but I find it
implies too little pub/sub. I'm currently using the term "broker"
instead. However, this is also the library name and could cause some
confusion. Internally, a "broker" maps to an actor (as in the actor
model). If anyone has suggestions on how to better name these abstract
pub/sub entities, please chime in.
To me a “broker” in a pub/sub system describes a thing that sits between publisher and subscribers (distinct from either) and manages the flow/filtering of messages. The internals of the library itself, already named Broker, do seem to serve that role, and so naming another thing “broker” adds confusion.
Ideas fort improving the name of “endpoint”:
(1) Make up a name that looks/sounds like pub/sub. e.g. call it a “pubsub” or a “pubsubber”
(2) Try to decouple the publisher and subscriber features into two separate classes and just literally name them “publisher” and “subscriber”.
