[zeromq-dev] Moving to 0MQ/3.0, yes or no?

[Martin Sustrik]

Hi Brian,

Thanks for the detailed discussion of the problem!

> * Breaking backwards compat to fix past design flaws is absolutely
> important and 3.0 provides a good place to pursue these things.

Ok.

> * These things should be handled with an incremental approach.  Flaws
> should be tackled one by one with community discussion.

Would you prefer having multiple backwards incompatible versions than 
having one? My thinking was that users would prefer to get all the 
backward incompatible changes in a single batch so that transition pain 
is minimised and in the future there's no need to deal with many 
mutually incompatible versions.

> * I don't think that "removing functionality" (PAIR sockets,
> zmq_device) should be considered unless we are absolutely sure that no
> one is using it or it is fundamentally broken.  If the current
> implementations have problems that required API changes to fix, then
> lets pursue that.  But merely removing things that users are actually
> using will only make people mad.

Let me explain. One of the main incentives for me to move to 3.0 was to 
clean up the semantics of messaging patterns. My feeling -- and I may be 
wrong -- is that it's the only way forward. However, cleaning up the 
messaging pattern semantics affects the very core of the system. It by 
its very nature breaks some of the existing applications and it breaks 
them in a way that can't be easily worked around by building a 
compatibility wrapper on top of the API or somesuch. There's not even a 
clear migration plan for the existing applications. If the pattern is 
vague, people are using it in different unforseen ways which we may not 
be even aware of. Tightening the semantics of the pattern is then almost 
necessarily going to break some of the existing applications. This was 
pretty obvious in recent discussions. In short, there's no easy way out.

If I am to use your LEGO brick analogy: If we are going to change the 
shapes of the bricks, we can't guarantee that people will be able to 
build the exactly the same structures as before.

Thus, my proposal is to start treating 0MQ as a stable product and 
simply admit there are some design flaws we are baked so firmly into the 
product that we are stuck with them forever. Instead we should focus 
focus on fixing bugs, making the users life easier e.g. by working on 
better packaging etc.

Makes sense?
Martin