On 01/20/2013 05:50 PM, Fraser Adams wrote:
It's starting to become somewhat clearer how proton fits in, though some of your comments still leave me with questions about how *ready* proton is yet - it looks though the C++ stuff is more advanced than the Java stuff - is that accurate?
Yes, but the gap is closing fast.
Is there a mechanism to get a JMS API around the Java proton messenger library or would Java AMQP clients still have to talk with the underlying proton API?
There is already an AMQP 1.0 implementation of JMS in Qpid. It predates the proton work but the plan is to replace it with something that uses proton underneath at some point (more to ease future maintenance).
I sort of see what you mean by your comment "Ultimately the vision behind AMQP is all about choice" perhaps that's fine but I think there needs to be some good guidance, patterns if you will for different use-cases. As an example qpid::client and qpid::messaging also offered a choice and you and I both know that that's now a bit of a slow motion car crash. Without strong guidance I think we'll not so much have "choice" as chaos.
I think with qpid::client it was very much a case of one being deprecated in favour of the other. In hindsight we could have been a lot clearer about signalling that.
With messenger v. qpid::messaging it is more a question of two different styles. There may be use cases that firmly imply one or the other, but I think that in large part it may come down to preference for one style or another.
I think that there's scope for confusion in python land too - you mention the deprecated library, so I *think* that this means that the favoured one is a SWIG wrapper round qpid::messaging - is that correct.
Thats not actually what I meant. In python there is the equivalent of the old qpid::client API expcept (it's not called that and quite different in actual methods/classes).
However you do raise a good point. At present there is no AMQP 1.0 implementation of the python qpid.messaging library. There *is* the SWIG wrapped equivalent from the c++ side (and this can be made to support AMQP 1.0) which is now pretty close to the native python API in behaviour.
One interesting question is how to proceed there. Is there for example sufficient interest and demand for (or interest in implementing) a pure python, AMQP 1.0 implementation of that library or is the SWIG version a good enough option? I don't know the answer, but collectively this list is the place to answer it I think.
I suspect that there are plenty of people confused by which to use and I think there's definitely a need for good documentation and examples.
Agreed. People need to be able to quickly get a sense for what a given API can and can't do, and what it is like to code with.
Some other concerns/thoughts. You mentioned "There has also been work to add 1.0 support to ActiveMQ, and that also uses the (java version) of the proton protocol engine." on one hand that's great from an interoperability perspective but again has the potential to cause huge amounts of confusion!! There needs to be some investment in "branding" IMHO for example how would one make a choice between ActiveMQ versus say the Qpid Java broker?
Again, a very good question.
These sorts of choices are very real indeed. In a corporate sense one often has to do make choices over messaging systems and it's hard enough as it is!!!!! I've got the T-shirt there when looking at Qpid versus Tibco and justifying choices to non-techies is nobody's idea of fun :-( there needs to be some strong differentiators for the "hard of thinking".
He he, I do like that phrase! I do totally agree with your point on clear differentiation. I think the success of AMQP 1.0 and the upcoming work on ActiveMQ does change the picture there somewhat and we need to discuss that as a community.
You also mention "qpid::messaging has an optional dependency on the c version of proton". Does this imply that proton is written in C (as opposed to C++)? Just curious on that one.
Yes, it is pure C.
And don't get me started on QMF. There's two protocols for starters :-) then there's a Java implementation by yours truly that is still stuck in a Jira, a C++ API that bears no relationship to the published (but still draft) QMF2 API, two python implementations (one for each protocol). I don't know if things have changed lately but the python tools used to use the QMF1 API for a long time. Around this time last year there was some talk of a QMF2 sub-project given that it has application beyond Qpid given that it's a fairly good request/response API with service discovery, but discussion on that (certainly in the Qpid Users mailing list) has fizzled out. I really like QMF and as you can probably see I've done a fair bit with it, but my motivation is waning a bit given that I'm not at all clear on the status of it all.
First off, thanks and congratulations on what looks like a very nice new component (I haven't had a chance to unbundle and play with it yet but will do that asap)! It looks very much like something that should be included somewhere in the main svn (under extras seems like a good home initially).
Second, I share your love-hate relationship with QMF! I do love the simplicity of the overall approach (simply sending & receiving messages); I'm a lot more reticent about particular APIs though.
--------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
