On Wed, Jul 10, 2013 at 03:54:44PM +0100, Gordon Sim wrote: > On 07/10/2013 01:45 PM, Darryl L. Pierce wrote: > >On Tue, Jul 09, 2013 at 04:01:02PM -0400, Ted Ross wrote: > >>I would think that downstream repos would package one or the other > >>but not both. It would be nice if downstream, it was called > >>qpid.messagingregardless of the implementation used. > > > >Agreed. > > I disagree. I can see cases where it would be beneficial to have > both installed. E.g. you have existing applications that you don't > want to switch (if it ain't broke etc), but you also want to try 1.0 > (or just the c++ impl) for some new use cases.
I can see someone wanting to try out 1.0, but they'll still eventually have to make a decision, right? If they go with the swigged APIs then they should be able to drop in the updated APIs with as little impact on their code as possible, IMO. Regarding not wanting to refactor existing apps that work, etc., that can be handled by the administrators by putting the old Python bindings in a separate location from the newer bindings by naming the eggs differently; i.e., python-qpid is the old API set while python-qpid_messaging is the newer set. Using pkg_resources the app developer can have both APIs living on the same machine, using the same packages, without collision. > >I think it ought to be a goal to have the Swigged bindings be a > >drop-in replacement for the pure Python bindings. The users shouldn't care > >which implementation they use. > > Some won't, some will. > > Though the APIs are getting very close, there are still - and I > believe will always be - behavioural differences. Even apart from > those, we have had users using eventlet and monkey-patching and they > are going to care which implementation they have. I'm not sure how to respond to that. The behavioral differences will result in large differences in how the APIs are expected to work? For the latter case, I see what you're saying. It'll be an issue, and I'd love to get some of them involved in discussions regarding this. > >WRT the name space, I'm still wanting to keep it as qpid.messaging > >since, in the long run, that would require developers to not change > >their imports and usage. > > I want to keep qpid.messaging for the existing python client, have > the swigged implementation available through another name and > optionally have a third that simply tries one and falls back on the > other based on what is available (for those use cases that want to > be able to switch between the two). My main issue is looking at the pure Python bindings and limiting what feels, to me at least, the package name for the swigged bindings due to that. I think we can overcome that without having extra packages on top of them. -- Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc. Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/
pgp1xqkryeOUz.pgp
Description: PGP signature
