[zeromq-dev] DEALER-ROUTER question

Goswin von Brederlow goswin-v-b at web.de
Fri Sep 26 19:50:20 CEST 2014

On Fri, Sep 26, 2014 at 06:34:32PM +0200, Pieter Hintjens wrote:
> On Fri, Sep 26, 2014 at 6:20 PM, Goswin von Brederlow <goswin-v-b at web.de> wrote:
> > Do you actually need it?
> After all the work, that's a sad question. What I see are too-large
> patches done in "I want to try this yet I've not defined a clean
> problem statement" directions, which stress other people, create lots
> of discussion and other patches, and then ultimately in "do we really
> need it?"
> Having to ask this question is totally, horribly wrong. I've
> personally spent something like 30-40 hours on the containers, mostly
> driven by the original zdlist patch. That seems to be about 75% wasted
> time.

I'm not talking about the doubly linked list part. Just about the
doubly linked list + zhash combo part. Both doubly linked list and
zhash are usefull on their own as are all the other changes we made
with the global destructor, duplicator and comparator.

How much of the time was spend on merging zhash support into zring?
How much was spend on improving the containers overall? I don't think
you spend 75% of the time on the merging and only that small part
would be wasted.

> This is what the whole process is about. I'm going to ask people who
> contribute to CZMQ to read the C4 document again and again until this
> kind of thrashing ends.

I think I followed that:

    If the Platform implements pull requests as issues, a Contributor
    MAY directly send a pull request without logging a separate issue.

I think what doesn't quite work right is this:

    Maintainers SHOULD ask for improvements to incorrect patches and
    SHOULD reject incorrect patches if the Contributor does not
    respond constructively.

For example in a recent pull request the zlist_goto was objected to,
accoring with:

    To discuss a patch, people MAY comment on the Platform pull
    request, on the commit, or elsewhere. 

But minutes later the patch was merged instead of waiting for the
discussion to conclude and the pull request getting updated with a
better patch.

I'm not sure how one is supposed to go from a first draft to solve a
problem to a release ready solution under the C4 process without "this
kind of trashing". New features and ideas don't pop up perfect. My
solution might not be to your liking. Like you didn't like the
zlist_node_t approach or the zring_goto wasn't liked. But my stated
problem needs exactly that feature. Finding a solution that is
acceptable by everyone takes a few tries.

When I try to discuss a possible sollution before submitting code you
say: Show me the code. When I show you code you complain about
trashing. So I'm a bit lost how you think this should work.

Or should I go off on my own, write 10 new classes to solve a complex
problem and then after a year submitt them all in one go as finished
solution without asking for any feedback along the way? I thought
splitting the problem into managable chunks and sending pull request
as chunks become ready was better. "Release early, release often".

> Anyhow, please don't remove zring, if it ends up being unused, it'll
> die naturally.
> -Pieter

You want to add a new but totaly unused class to the next stable
release so it can die naturally?

If you have a use for the combo of them then that is fine. You added
that part to zring so you must have had a reason. I just don't see one
at the moment now that zcertstore simply iterates over zhash. I didn't
like mixing zdlist and zhash into a single zring class from the start.
It wasn't needed with my original patch.


More information about the zeromq-dev mailing list