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

[Pieter Hintjens]

On Mon, Apr 11, 2011 at 2:56 PM, Martin Sustrik <sustrik at 250bpm.com> wrote:

> 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.

You need to document what you mean here. What's currently broken, what
are the consequences, what are the different options...

>  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.

I'd say, you have existing lego pieces (socket types) which work. You
can make new ones. Applications can use which ever ones they like.
Don't break old pieces. It's simple enough. The existing patterns
aren't vague, nor arbitrary, and afaik there are very few undocumented
side effects that people rely on.

> If the pattern is
> vague, people are using it in different unforseen ways which we may not
> be even aware of.

Not a proven problem, you can't use this as argumentation without
proof. The semantics of the existing socket types are extremely well
documented, and used accurately. I've seen *one* report of a
side-effect, which I pointed you to last week, a pub socket that will
not discard messages while it's trying to connect to a sub socket.

> 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.

You don't tighten semantics that already work and are widely used,
obviously. Make new ones, independently. If your new semantics are
really better, people will use them.

> 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.

Don't change the shape of bricks that work and are used.

> 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.

This appears to be a false dichotomy based on the assumption that you
cannot invent new lego bricks.

-Pieter