[zeromq-dev] multi-part messages

[Martin Lucina]

Pieter,

On Tue, 24 Jan 2012 11:59:18 -0600
Pieter Hintjens <ph at imatix.com> wrote:

> On Mon, Jan 23, 2012 at 6:45 PM, Martin Sustrik <sustrik at 250bpm.com> wrote:
> 
> > It's a backward incompatible change. The problem with backward
> > incompatible changes is that you can do them only so often, if at all.
> > The reason being that you are forcing 1000s of users through the pain of
> > upgrading, rewriting their application code, re-testing etc.
> 
> Well... this is just a matter of will power. There is no reason new
> features have to break old ones.

... if and only if you have unlimited developer resources and prefer
maintaining backward compatibility above all else! [1]

In the case of libzmq, the core developer resources are very much
limited, so the choices going forward are also limited. This may
actually be a good thing since even though it "annoys" users expecting
a stable product, the end result is a smaller, simpler and more elegant
iteration of ZeroMQ.
 
> Say you want to introduce labels. What you do first is allow the
> protocol to support these without breaking. There have been proposals
> for that, we can revisit them if needed. Second, you expose labels via
> NEW socket types so you don't break old code. Third, as the new
> features become stable you deprecate the old features. Finally, some
> years later, you remove them.

Having done some substantial work on the libzmq core code recently [2] I
can tell you that the multipart message support affects all parts of
the codebase.

Same goes for the old identities/durable sockets which got ripped out
of 3.1; there are still various leftovers from that in the codebase
which unnecessarily complicate things and should be excised ASAP. Martin
Sustrik has said several times that the identity support is like a
cancer on the codebase and I completely agree.
 
> This is tried and tested practice. The fault with 3.0 and 4.x was
> ignoring cost/benefit and simply breaking old code with no attempt to
> provide an upgrade path. That's what people disliked, and that's why
> those branches were not used.

I don't think Martin is ignoring anyone intentionally, just trying to
get the best result with the least possible resources.

-mato

[1] your name is Bill and what you end up with is Windows.
[2] hopefully to be released publicly some time in the next month or
so, watch this list...
-- 
Martin Lucina <martin at lucina.net>