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