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 <[email protected]> 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
[email protected]
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
_______________________________________________
zeromq-dev mailing list
[email protected]
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
