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. ~ Nathan
_______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
