[zeromq-dev] ZMQ_IDENTITY revisited

[Pieter Hintjens]

On Sun, Jul 10, 2011 at 12:57 PM, Martin Sustrik <sustrik at 250bpm.com> wrote:

> So, what will happen is that we'll have 0MQ/2.x (old API, ZMQ_IDENTITY),
> 0MQ/3.x (new API, ZMQ_IDENTITY) and 0MQ/4.x (new API, no ZMQ_IDENTITY).

So you're saying you want to skip from stable 2.x to 4.x without a
stable 3.x in between?

> 0MQ/2.x is maintained by Pieter, 0MQ/4.x (the master) will be maintained
> by myself, but it's not clear who's going to do maintenance (backporting
> bugfixes etc.) of 0MQ/3.x.

Backporting & maintenance is 100% a function of demand. No users = no
demand. Since there have been no packages for 3.x, it's fair to assume
there are _very_ few users.

> If not so, there's no much point in releasing 0MQ/3.0 and we should move
> directly to 0MQ/4.0, ie. new API without ZMQ_IDENTITY.

There's a few points here.

Most dangerously, Version 2 Syndrome. You are planning, afaics, to
change three major aspects of the stack at once. The external API, the
wire level protocol, and the internal architecture. This is risky. I'd
generally advise against it, except that (a) it worked for v2, and (b)
we have v2, so if this fails, it's not a major problem. But do watch
out for "change everything at once" syndrome. It's safer and often
easier to get stability in each area of change before starting on the
next one.

Next point, there's no visible benefit in skipping the 3.x version
like this. We don't have a stable 3.0 release. If you think that
removing identities is a good tradeoff, use the 3.x project for this.
Otherwise you're using major version numbers simply for experiments.

Next, you have new functionality in there like subscription forwarding
that _no-one_ will use and test under such conditions. 3.0 will be
abandoned? Who in their right minds would use it then.

Lastly, there are better ways to remove functionality. We've discussed
this. First, document use cases and discard the bogus ones. Second,
find workarounds for the real use cases. Third, deprecate the old
functionality. Finally, remove it.

So, my advice is to first make a stable 3.0 release, in which
deprecates durable sockets and perhaps removes them for certain socket
types. Package up all the work done so far and give that a chance to
become mature. Then, based on that, remove explicit identities in 3.1,
after you've helped users migrate existing use cases (such as
router-router work, as in the Freelance pattern).

-Pieter