[zeromq-dev] libzmq v4.0.5

[Goswin von Brederlow]

On Wed, Sep 24, 2014 at 05:46:14PM +0200, Pieter Hintjens wrote:
> Sorry for using the word "criminal". I meant, just, that this would be
> a contract violation. Since ZeroMQ v3.2, we've held to the principle
> that new functionality may not break existing apps. We broke this rule
> once or twice afaik.
> 
> 
> 
> On Wed, Sep 24, 2014 at 12:07 PM, Pieter Hintjens <ph at imatix.com> wrote:
> > No, we cannot and will not break existing public APIs. Please read the
> > C4 if you're not clear on this. Bumping the ABI version does not
> > excuse criminal behavior.
> >
> > We can at any point add new classes, and new methods. This is what
> > CZMQ is experimenting with. These classes can move into libzmq if
> > that's valuable.
> >
> >
> >
> > On Wed, Sep 24, 2014 at 8:33 AM, Goswin von Brederlow <goswin-v-b at web.de> wrote:
> >> On Mon, Sep 22, 2014 at 12:13:48AM +0200, Pieter Hintjens wrote:
> >>> Hi all,
> >>>
> >>> This is a pre-release announcement, to give time for backporting. If
> >>> there are any fixes on libzmq master that you'd like to see in 4.0.5,
> >>> please let us know. For info, this is what's currently in that
> >>> release:
> >>>
> >>> * Fixed #1191; CURVE mechanism does not verify short term nonces.
> >>> * Fixed #1190; stream_engine is vulnerable to downgrade attacks.
> >>> * Fixed #1088; assertion failure for WSAENOTSOCK on Windows.
> >>> * Fixed #1015; race condition while connecting inproc sockets.
> >>> * Fixed #994; bump so library number to 4.0.0
> >>> * Fixed #939, assertion failed: !more (fq.cpp:99) after many ZAP requests.
> >>> * Fixed #872; lost first part of message over inproc://.
> >>> * Fixed #797, keep-alive on Windows.
> >>>
> >>> -Pieter
> >>
> >> If you bump the SOVERSION would it be possible to fix the void * for
> >> everything problem? Define a abstract ctx_t, sock_t, msg_t, ...?
> >>
> >> MfG
> >>         Goswin

Well, and a third time now. Both the "now blocks" and changed monitor
events are API changes that breaks existing stuff. One could even say
the ABI hasn't changed, only the API.

Which makes me wonder. How could we prevent this in the future?

It would be easy enough to add runtime options to the code to switch
between the old and new behaviour (at the cost of having to maintain
them). But I don't want to end up having to set 1000 flags to switch
on new features. Maybe we could add a new

    void zmq_init_ver (int io_threads, int api_version);

The zmq_init_ver would have a switch statement that would toggle
behavioural option on and off depending on the version passed to it.
Calling 'zmq_init_ver (1, 3);' would give the old behaviour while
'zmq_init_ver (1, 4);' would activate the behaviour we currently have
and remain there. When more changes are added a API version 5 would be
added, then 6 and so on.

Fuse has something similar but at a compile time property.
/usr/include/fuse/fuse.h:

     * This file defines the library interface of FUSE
     *
     * IMPORTANT: you should define FUSE_USE_VERSION before including this
     * header.  To use the newest API define it to 26 (recommended for any
     * new application), to use the old API define it to 21 (default) 22
     * or 25, to use the even older 1.X API define it to 11.
     */

    #ifndef FUSE_USE_VERSION
    #define FUSE_USE_VERSION 21
    #endif

Defining the FUSE_USE_VERSION in the application actually changes the
API and if unset you get the base version.


What do you think? Could we use one of those methods? Are there better
ways?

MfG
	Goswin