Hi Ken,
I guess the bit that you are alluding to below is:
##
## Check to see if the broker has QMFv2 exchanges configured
##
direct_result = self.amqpSession.exchange_query("qmf.default.direct")
topic_result = self.amqpSession.exchange_query("qmf.default.topic")
self.brokerSupportsV2 = not (direct_result.not_found or
topic_result.not_found)
I'm guessing that self.amqpSession.exchange_query relates to some AMQP
0.10 specific code similar to queue_declare/exchange_declare etc. I'm
not wildly familiar with those constructs as I've tried to stick to the
qpid::messaging and JMS APIs wherever I can, the stuff above appears to
be somewhat similar to things I've seen in qpid::client, though I've
generally avoided that like the plague.
I guess querying for the presence of the QMF2 exchanges in this way
avoids the conundrum of which QMF version to use to query for the
presence of the exchanges :-)
But OTOH am I correct that the constructs above relate to the pure
python implementation of AMQP 0.10? I suppose one thing to consider is
that there's now also an alternative python API/implementation based on
SWIG bindings to qpid::messaging and (I guess) the "low level" AMQP 0.10
constructs being used in console.py aren't available in the
new/alternative python API.
I guess following on from my usual broken record about cohesion and
communication it might be good if we can come out with a statement of
direction/roadmap with respect to some APIs. Given that proton/AMQP 1.0
is starting to take off and as discussed in other threads
qpid::messaging is here to stay and given some comments from Gordon that
it's likely that a pure python AMQP 1.0 is likely to be down the
priority list given the SWIG binding to qpid::messaging is it time to
start calling time on the current pure python AMQP 0.10. If not exactly
deprecate it yet then at least suggest the likely trajectory with some
putative dates.
I certainly wouldn't want to panic anyone!!!!!, this is purely my own
take, but I think without a few lines in the sand being drawn, even if
they are initially sketchy we really run the risk of confusing users as
the journey towards AMQP 1.0 progresses.
Is this worth discussing, or is everyone content with the status quo
position?
As a related aside ISTR one of my colleagues mention a memory leak with
the qpid::messaging python binding. I don't really use python in anger
myself so it's a bit third hand, is this something you are aware of? I
know that there were issues with perl that have recently been fixed, but
the comment made to me was about python. I'd definitely be interested to
know.
Frase.
On 02/04/13 22:22, Ken Giusti wrote:
When console.py connects to a broker (via addBroker), it will attempt to query
for the existence of the qmf.default.direct and qmf.default.topic exchanges.
If that query succeeds, the console marks that broker as being V2 capable, and
uses V2. Otherwise it falls back to V1.
Take a look at the Broker::_tryToConnect() method in console.py for all the
gory details.
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org
