[zeromq-dev] Behavior of Labels, Identities, and Socket Types in 3.0
Gregory Szorc
gregory.szorc at gmail.com
Thu Oct 27 20:06:54 CEST 2011
On 10/27/11 7:40 AM, Chuck Remes wrote:
> I like the concept of differentiating the envelope/labels from the message body. I would like to keep labels.
>
> Using an empty packet as a delimiter between envelope and body was a good first try, but labels are superior.
I agree.
One nit I have about the current implementation is how you need to
double dip into getsockopt when reading a multi-part message. On the
initial message(s), you always need to query LABEL. On the first
non-label message, you need to getsockopt again to determine if MORE are
available. On subsequent messages, you can bypass querying for LABEL, as
all labels must precede regular messages. Is this accurate, or can you
interleave label and non-label messages? Either way, double dipping
incurs more function calls, which can't be inlined (assuming a
dynamically linked libzmq). How about combining both queries into a
single getsockopt option and have macros for testing the set bitfield?
As for the whole to-label-or-not-to-label argument, as an end user (with
admittedly not very much skin in the game), I really don't care [too
much]. 3.0, with a new major version, is certainly the time to make such
drastic changes. And, as the popularity of the project grows, change now
will cause less user angst than change later. As long as the
documentation (everything from man pages to the guide) is proper and the
upgrade path is well-documented and supported, I'm game.
Going forward, I'd also like to see a more prominent notice that
versions (like master of 3.0 today) aren't stable and/or are half-baked.
The README would be a good location for an ALL CAPS WARNING. I realize
the beta tag implies some of this (but only a short while ago 0MQ was in
perpetual "stable" beta) and I know there are (probably) plenty of
warnings on this mailing list and IRC, but people shouldn't have to
exhaustively read the mailing list or lurk on IRC to discover this, IMO.
Greg
More information about the zeromq-dev
mailing list