On 07/10/2013 04:51 PM, Darryl L. Pierce wrote:
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?
The point is that the decision taken for one use case shouldn't
necessarily force the same choice across the board.
[...]
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 its important to keep the different notions of package separate.
On the one hand there is the python namespace. On the other hand there
is the platform specific installation approach in use (e.g. rpms or
whatever).
In the case of the latter, I think it is decidedly odd to e.g. yum
install python-qpid, yum install python-qpid_messaging and have the
installation of the second package overwrite artefacts of the first one
(even assuming this doesn't totally break things).
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?
There are differences, and those differences could mean that an
application that works with one does not work with the other.
To state the obvious, the swigged implementation is a different library
offering (broadly) the same API. It is not an evolution of the existing
implementation.
It is clearer to give these two different implementations two different
names.
I can certainly also see cases where users don't want to explicitly
choose one or the other and want their code to run against either
without change (I have that need myself as explained in an earlier
mail). However I think that can be done by a simple (5 line) module with
a third name.
That way users can pick one, or the other, or explicitly decide they
don't care and want to pick whichever is available based on path.
[...]
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.
I don't really understand what you are saying here. Are you saying you
want the name qpid.messaging for the swigged implementation because it's
a nicer name than alternatives?
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
