On 07/10/2013 10:47 PM, Darryl L. Pierce wrote:
I think your previous suggestion to have a compatibility import might be
the better way to go. How about something like this:
1. move the pure Python bindings to the qpid.pure package
I think we should leave the existing pure python client as it is (at the
very least for the time being). I see no convincing case to change what
that namespace refers to.
2. leave the Swig bindings in cqpid for the time being
I do think it might be worth considering a renaming of the swigged
client. This of course would need to be discussed on the user list first
to assess impact and opinion of those most effected.
3. create a new module that lives in qpid.messaging and which will
import either qpid.pure or cqpid depending on a setting from the
application importing them?
As above I think we should keep qpid.messaging to mean what it always
has. I'd suggest this third module be called qpid_messaging. (I'd
suggest the swigged version then be qpidc_messaging).
I started off thinking some sort of application setting might be good.
In the end I think the simplest solution is to use the path - prefer one
then fallback to the other. If the application code has to set a change
a variable then you sort of negate the point of the exercise (i.e. not
wanting to edit code).
Where there is an existing mechanism for runtime options (e.g. command
line options or a config file) then it is easy enough for users to build
the ability to switch more flexibly if it is important.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
