[zeromq-dev] question about the documentation to provide when adding a set of functions

[Laurent Alebarde]

No problem for me. I am here just to share.

Le 05/02/2014 12:51, Pieter Hintjens a écrit :
> On Wed, Feb 5, 2014 at 12:36 PM, Laurent Alebarde <l.alebarde at free.fr> wrote:
>
>> If you have another suggestion for 'zmq_proxy_open_chain' that makes more
>> sense for you, I will change it. But with my explanations and
>> justifications, I find it right IMHO and have no other suggestion myself.
> I'm still mystified why you're adding this complexity to the core API,
> you've not explained what *problem* you're solving. That means, what
> you are trying to do that you CANNOT do today.
Of course you can do the same without the zmq_proxy_open_chain family 
functions. But then, you can remove all proxy and device functions. 
IMHO, a library is useful if it is convenient to use and opened for 
improvements. How I see it is a core functions, let say simple functions 
or raw functions that enable to perform anything, and higher level 
functions to share often used paradigms, so that everyone do not need to 
reinvent the wheel for each need. It is like the Git's porcelain / 
plumbing API. But possibly this would be better in czmq ?
>
> What is a "proxy open chain"?
>
> "zmq_proxy_open_chain_set_socket_events_mask"
>
> Seriously? You think this is OK?
For me yes, but as I said, I am al-right for any other name.
>
>> typedef struct zmq_proxy_open_chain_t {unsigned char _ [496];}
> Again, seriously? Magic numbers? We do this for zmq_msg for
> unfortunate historic reasons. It is _very bad_ API design.
I just tried to be conform with what exists in the code. I have found it 
awful too. And it is not commented as awful in the code. It should be.
>
> Look, Laurent, our process calls for small incremental improvements
> that fix agreed problems. Please read RFC 22 again if you're unsure.
>
> You're making a mess here. I don't like messes in our core library.
So I won't pull request unless several users ask it for. In the time 
between, it remains on my repository for any one to use it, in a branch 
in the future.
>
> Please take this API out again, until you get some consensus from the
> list on the need for it. Then, make it in minimal steps.
>
> If you make this patch I'll merge it, and then I shall remove it.
> There is zero reason to be making complex proxy layers in libzmq. Even
> in CZMQ I've had to remove all calls to zmq_proxy_steerable and write
> my own proxy code, it's much simpler and backwards compatible.
>
> Thanks for keeping things simple. Less is more.
But more is better, just a point of view.
>
> Pieter
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20140205/83e22d3f/attachment.htm>