On Mon, Apr 11, 2011 at 2:56 PM, Martin Sustrik <[email protected]> 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 _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
