Please be considerate of downstream users and keep the zmq_device() stuff for the duration of the current major release? I mean you can add a zmq_proxy() by all means, but please keep zmq_device() as an alias, along with any constants (if any) that has to do with the device stuff so our existing code still work.
Once the major version number bumps up, go ahead and remove it. This would make us binding authors' life much easier. --d 2012/9/8 MinRK <benjami...@gmail.com>: > > > On Fri, Sep 7, 2012 at 12:48 PM, Nathan <nathan.sto...@gmail.com> wrote: >> >> On Fri, Sep 7, 2012 at 12:39 PM, MinRK <benjami...@gmail.com> wrote: >>> >>> >>> >>> On Fri, Sep 7, 2012 at 3:25 AM, Ian Barber <ian.bar...@gmail.com> wrote: >>>> >>>> On Fri, Sep 7, 2012 at 11:03 AM, Pieter Hintjens <p...@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@lists.zeromq.org >> http://lists.zeromq.org/mailman/listinfo/zeromq-dev >> > > > _______________________________________________ > zeromq-dev mailing list > zeromq-dev@lists.zeromq.org > http://lists.zeromq.org/mailman/listinfo/zeromq-dev > _______________________________________________ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
