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 <[email protected]> wrote: > > > On Fri, Sep 7, 2012 at 12:48 PM, Nathan <[email protected]> wrote: >> >> On Fri, Sep 7, 2012 at 12:39 PM, MinRK <[email protected]> wrote: >>> >>> >>> >>> On Fri, Sep 7, 2012 at 3:25 AM, Ian Barber <[email protected]> wrote: >>>> >>>> On Fri, Sep 7, 2012 at 11:03 AM, Pieter Hintjens <[email protected]> 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 >> [email protected] >> http://lists.zeromq.org/mailman/listinfo/zeromq-dev >> > > > _______________________________________________ > zeromq-dev mailing list > [email protected] > http://lists.zeromq.org/mailman/listinfo/zeromq-dev > -- Brian E. Granger Cal Poly State University, San Luis Obispo [email protected] and [email protected] _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
