On Wed, 2021-02-03 at 17:53 +0000, Fraser Adams wrote: > Can I just check something? > The implication from https://qpid.apache.org/download.html is that > the > Python Qpid Messaging API > <https://qpid.apache.org/components/messaging-api/index.html> is > Python2 > only and that same page says "Look to the newer Qpid Proton > <http://qpid.apache.org/proton> for Python 3 and AMQP 1.0 support.". > > As I understand it Proton is purely for AMQP 1.0, correct?
So far this all seems correct. > > So this all seems to be saying that there is basically no Python3 > AMQP > 0.10 client available - is that correct? Again (as far as I know) this is correct. To be sure afaik no one has spent much time considering how to port this to python 3. So if you are interested go ahead - to be extra clear going forward you would need to do this as python 2 support is gradually waning entirely! Having said that are you really still using AMQP 0.10? Gosh if so! > > One fairly nice thing about the Qpid Messaging API was that it was > quite > a high level API with quite a few parallels with JMS and it was > possible > to use the same "Address Strings" which was quite handy if you had a > heterogenous set of Java, C++ and Python client applications > connecting > to brokers. > > It has been a while since I last looked, but Proton has always felt > that > bit lower-level. The Proton python binding is not low level, I'd say it is medium to high level! The C API is certianly low level, but the bindings are all significantly higher. Having said that I doubt the identical "address strings" would work. > > > I think having Proton as the only Python3 client is somewhat de facto Sure - no one seems to want to maintain the qpid messaging python client! > implying that AMQP 0.10 support is being deprecated too. Wouldn't you say that as far as Qpid is concerned we did that (de facto) years ago? > I know that > there is a degree of heterogeneity in the brokers, so it's not quite > as > stark as that, but OTOH I think that the picture is maybe a bit > confusing for people looking at AMQP and trying to make informed > decisions between Rabbit, Apid, ActiveMQ, whatever. > > As a concrete example of that last point I'm currently working on a > project where I ended up using RabbitMQ because that was what other > team > members were familiar with. We're using Pika as the Python client, > but I > ended up writing a thin wrapper round that to make it look more JMS- > like > (and more like Qpid messaging). TBH part of the reasoning was also > that > I'd have quite liked the option to switch to Qpid which *should* have > been fairly straightforward, but the lack of a Python3 Qpid Messaging > style API makes that more of a PITA than it really ought to be TBH. I'd say the BlockingConnection style of code from the proton python binding is fairly close to qpid messaging in many ways, although the 'official' API is certainly callback/event based. > > A nice asyncio based JMS-like API in the same vein as the JMS/Qpid > Messaging APIs would be kind on nice, but ho hum Certainly agree about that - only so many hours in the day and all that! Andrew --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
