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