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 _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
