[zeromq-dev] 0MQ/3.0, 0MQ/4.0 and 0MQ process

[Martin Sustrik]

Hi Chuck,

 > Main development should be on libzmq.

The question is whether to start with zeromq3-0 repo or libzmq repo. Are 
there any technical considerations? The log seems go back to initial 
version of 2.0 (summer 2009) in both repos.

 From social perspective libzmq has more watchers than 3-0, which may 
make it preferable.

 > BTW, if that
 > happens frequently (master diverges rapidly so patches don't apply)
 > then we aren't making releases often enough!

The above doesn't apply to maintenance branches such that have to be 
kept backward compatible for years, with only bugfixes being backported.

 > I will miss the explicit label stuff. I hope it makes a comeback in
 > the future. I am *not* a fan of using an empty message as a delimiter
 > between the routing envelope and the body in multipart messages, but
 > I can live with it for now.

Yes. Labels are technically a better solution and they should be 
introduced at some point -- I think there's a consensus about that. 
However, at the moment we are solving the migration problem caused by 
half-assed implementation of labels in current 3-0.

I would say, let's create a new "labels" topic branch and put the code 
there. The change should affect whole req/rep family of socket types 
though, not just some of them.

At some point we'll have to modify the guide and the examples in it to 
reflect the change and release it.

 > Is your proposal to keep the longer identities? Or will we be able to
 > explicitly set them but they must fit within 4 bytes now?

I want it to be backward compatible with 2.1, meaning that explicit 
identities can have arbitrary length. Auto-generated identities can be 
either 4 bytes long, if people are happy with that, or 17 bytes long (4 
bytes + 13 bytes of padding) if it's considered necessary for backward 
compatibility.

 > My one concern that prevents me from wholeheartedly backing this
 > proposal is the abandonment of 3.0 early adopters. Can you (or
 > someone) detail precisely which pieces will break for them? Is it
 > *only* the label stuff?

Yes. It's label stuff. Also, there a split between XREQ/XREP and 
ROUTER/DEALER which can be removed if needed. The only difference at 
this point is that XREQ/XREP drop queued requests and replies for 
disconnected clients, meaning that queued tasks that have nobody to 
receive the reply are not processed at all by the server side.

Pieter,

 > Me too. There's not much impact on the Guide for these changes.
 > However the new ROUTER socket does dramatically change things.

Yes. The new ROUTER socket should be on a topic branch, not in the trunk.

Gregory,

 > I /think/ reverting this also means that 2.1 and 3.0 will speak
 > the same wire format. Or, is there something else that changed
 > besides adding the LABEL bit to the per-message flags?

If there was any additional change in request/reply family of socket, it 
should be reverted as well.

Note, however, that publish/subscribe wire protocol have changed 
(subscriptions forwarding was added) and that part is going to stay.

Mikko,

 > from contributors (my) view the multiple repos and processes has never
 > worked really well. There is certain amount of confusion of how to get
 > patch into different repositories and how to follow a patch throughout
 > different versions.
 >
 > I am all in (as I have been always) for single repository and single
 > process for all the development. There should be no need to create
 > multiple forks inside a single organisation for things that can be
 > done in branches inside a single repository.

Yes. However, to do that we have to solve the "ego" problem. It actually 
boils down to only couple of policies that Pieter and myself differ on. 
We can for example do a community vote on these and impose the resulting 
policies on the maintainer(s) of the single common repo.

These differing policies are (Pieter, feel free to add those that I've 
missed):

1. Sign-offs. These are required by myself but not required by Pieter. 
The idea of sign-off is as follows: If the contributor modified the 
codebase and sends the patch, it's a derivative work and it's 
automatically covered by LGPL. However, if the contributor uses an 
existing code from another source, there may be a licensing conflict. 
The sign-off is a confirmation from the author that there's no such 
conflict. The actual text of the confirmation can be found here:

http://www.zeromq.org/docs:contributing#toc5

2. Sending the patches to the mailing list vs. pull requests. I prefer 
the former as it is publicly visible and allows for developer feedback.

3. Merging in hacks, ie. patches that apparently solve a problem, 
however, they do it be ignoring the underlying cause of the problem.

Thoughts?
Martin