[zeromq-dev] Pull request to retire "devices" and replace with "proxies"

Nathan nathan.stocks at gmail.com
Fri Sep 7 21:48:13 CEST 2012

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
> name.
> 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
> zmq.proxies.ThreadProxy?
> 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.

~ Nathan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20120907/7e68142b/attachment.htm>

More information about the zeromq-dev mailing list