[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
etc.

...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