<br><br><div class="gmail_quote">On Sun, Sep 9, 2012 at 4:28 PM, Daisuke Maki <span dir="ltr"><<a href="mailto:lestrrat@gmail.com" target="_blank">lestrrat@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

Please be considerate of downstream users and keep the zmq_device()<br>
stuff for the duration of the current major release? I mean you can<br>
add a zmq_proxy() by all means, but please keep zmq_device() as an<br>
alias, along with any constants (if any) that has to do with the<br>
device stuff so our existing code still work.<br>
<br>
Once the major version number bumps up, go ahead and remove it.<br>
This would make us binding authors' life much easier.<br></blockquote><div><br></div><div>Pieter is not removing zmq_device, only adding a new name for it.</div><div>The old name remains, and will presumably be deprecated in some distant future.</div>

<div><br></div><div>The 'current' major release is actually 2.x, which is unaffected.</div><div>There has still yet to be a single stable 3.x release.</div><div><br></div><div>-MinRK</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


<br>
<br>
--d<br>
<br>
2012/9/8 MinRK <<a href="mailto:benjaminrk@gmail.com">benjaminrk@gmail.com</a>>:<br>
<div class="HOEnZb"><div class="h5">><br>
><br>
> On Fri, Sep 7, 2012 at 12:48 PM, Nathan <<a href="mailto:nathan.stocks@gmail.com">nathan.stocks@gmail.com</a>> wrote:<br>
>><br>
>> On Fri, Sep 7, 2012 at 12:39 PM, MinRK <<a href="mailto:benjaminrk@gmail.com">benjaminrk@gmail.com</a>> wrote:<br>
>>><br>
>>><br>
>>><br>
>>> On Fri, Sep 7, 2012 at 3:25 AM, Ian Barber <<a href="mailto:ian.barber@gmail.com">ian.barber@gmail.com</a>> wrote:<br>
>>>><br>
>>>> On Fri, Sep 7, 2012 at 11:03 AM, Pieter Hintjens <<a href="mailto:ph@imatix.com">ph@imatix.com</a>> wrote:<br>
>>>> > Hi all,<br>
>>>> ><br>
>>>> > From <a href="https://github.com/zeromq/libzmq/pull/422" target="_blank">https://github.com/zeromq/libzmq/pull/422</a><br>
>>>> ><br>
>>>><br>
>>>> LGTM. I think the proxy name fits the concept better, particularly<br>
>>>> with the capture socket option (which is very akin to the monitored<br>
>>>> device in pyzmq iirc). It kind of frees up the language as well - if<br>
>>>> someone does want to build a little service that does some work they<br>
>>>> can call it a device without it being confused with the zmq_device<br>
>>>> function to - though as you say that hasn't happened that much!<br>
>>><br>
>>><br>
>>> I agree that proxy is a better name,<br>
>>> though I am not certain the cost of renaming is outweighed by the better<br>
>>> name.<br>
>>><br>
>>> I have a practical question as maintainer of pyzmq.<br>
>>><br>
>>> PyZMQ has a notion of 'devices', e.g.<br>
>>><br>
>>>     from zmq.devices import monitored_queue<br>
>>><br>
>>> for the device derivative Ian alluded to, or<br>
>>><br>
>>>     from zmq.devices import ThreadDevice<br>
>>><br>
>>> for a class that runs zmq_device in a GIL-less background thread<br>
>>><br>
>>> Does this suggest that I should now be moving these to zmq.proxies, and<br>
>>> zmq.proxies.ThreadProxy?<br>
>>><br>
>>> I know I will get loads of complaints from users for changing APIs simply<br>
>>> because the name is better,<br>
>>> but at least I can tell them to email Pieter :)<br>
>>><br>
>>> One comment on the capture socket: When I wrote the monitored queue which<br>
>>> does essentially the same thing,<br>
>>> I needed direction information (whether the message came from the<br>
>>> frontend or the backend), rather than<br>
>>> just publishing everything as-is.  This allows a design where one SUB<br>
>>> socket can monitor messages<br>
>>> from a collection of proxies, and know where messages are coming from<br>
>>> (frontend/backend as well as which proxy).<br>
>>><br>
>><br>
>> If you are concerned about keeping backwards compatibility it is as easy<br>
>> as leaving a devices module with:<br>
>><br>
>> ThreadDevice =  proxies.ThreadProxy<br>
>> etc.<br>
>><br>
>> ...and documenting that they are deprecated, point to what to use going<br>
>> forward, and removing the compatibility layer at some point in the future.<br>
><br>
><br>
> Yes, I would certainly do that.  But deprecating names is not significantly<br>
> less painful than simply changing them, as people still have to update their<br>
> code in the exact same way, just not so abruptly. And they will rightfully<br>
> complain that they are getting nothing for their trouble.<br>
><br>
>><br>
>><br>
>> ~ Nathan<br>
>><br>
>> _______________________________________________<br>
>> zeromq-dev mailing list<br>
>> <a href="mailto:zeromq-dev@lists.zeromq.org">zeromq-dev@lists.zeromq.org</a><br>
>> <a href="http://lists.zeromq.org/mailman/listinfo/zeromq-dev" target="_blank">http://lists.zeromq.org/mailman/listinfo/zeromq-dev</a><br>
>><br>
><br>
><br>
> _______________________________________________<br>
> zeromq-dev mailing list<br>
> <a href="mailto:zeromq-dev@lists.zeromq.org">zeromq-dev@lists.zeromq.org</a><br>
> <a href="http://lists.zeromq.org/mailman/listinfo/zeromq-dev" target="_blank">http://lists.zeromq.org/mailman/listinfo/zeromq-dev</a><br>
><br>
_______________________________________________<br>
zeromq-dev mailing list<br>
<a href="mailto:zeromq-dev@lists.zeromq.org">zeromq-dev@lists.zeromq.org</a><br>
<a href="http://lists.zeromq.org/mailman/listinfo/zeromq-dev" target="_blank">http://lists.zeromq.org/mailman/listinfo/zeromq-dev</a><br>
</div></div></blockquote></div><br>