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

[Brian Granger]

I have not followed this very closely, but it is not clear to me that
proxy is better than device.  I can definitely imagine usage cases for
devices that are not very proxy-ish.  I probably also don't feel that
the trouble of renaming is worth it.

Cheers,

Brian

On Fri, Sep 7, 2012 at 12:53 PM, MinRK <benjaminrk at gmail.com> wrote:
>
>
> 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
>>> 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.
>
>
> 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
>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>
>
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>



-- 
Brian E. Granger
Cal Poly State University, San Luis Obispo
bgranger at calpoly.edu and ellisonbg at gmail.com