Hi Frase and others.
It is regrettable that there is so much confusion. I understand where you're coming from. Indeed I think I have had similar experiences with some of the changes that you have had and are experiencing. Before addressing some specific API issues I think it's first worth explaining Qpid Proton. It looks like you have a handle on it now but I'll try to explain again as I understand it. When looking at implementing AMQP 1.0 it was decided that rather than try to implement it inside the much evolved Qpid, especially qpidd, it would be best to implement AMQP 1.0 as a library that was plugable into other artifacts like qpidd (and for example ActiveMQ). Let's create a pure AMQP 1.0 implementation that can be consumed by others. It was decided to build two libraries, one in C and one in Java. The Java can then be consumed by JMS implementation such as Qpid or ActiveMQ or others. The C implementation can be the bases for other non-Java implmentations, e.g. Qpid's C++. With SWIG we could generate other language bindings on the base API (called the Engine). As it turns out there was a second API build on top of the core Engine API. This Messenger API provides a wrapper on top of the Engine to provide a very simple (yet very powerful) API for develops that care little about complicated use cases but instead want to just publish and subscribe for messages as simple as possible. This is a really cool for things like Python and Ruby etc. But I've actually used the C based Messenger API to build bridge for the OpenMAMA project. So far it seems to be working fine - but I can always go back to Engine if I find I need some more complex semantics and message flows. So Ted's email was, as the subject said, in reference to the Messenger API. It is not to do with the JMS API. Many, or perhaps I should say several, of us believe that AMQP is not limited to traditional MOM like deployments. We believe, in the near term, that AMQP will be used mostly for MOM. However in the future we see that AMQP could, if we don't screw it up, become a popular protocol for building internet applications that require more asynch messaging patterns. AMQP can help app developers avoid some of the unnatural gymnastics that they currently have to perform when using HTTP. For that reason we think the world won't all be about JMS - there will still be a lot of it and, good news, it will interoperate with everything else. Messenger allows app develops access the power of messaging and in particular AMQP without having to learn much. Having said that if they want to dive in more they will find many common patterns and APIs to support those patterns. So Ted was looking at the current Messenger API that is part of Qpid Proton and saying, hey for people using this API wouldn't it be nice if ... Remember, people using the Messenger API are not JMS developers. Now the community does need to do a much better job of making these points clearer. The websites are, as you point out, not well linked or explained. So here is some more explanation at a high level: qpid::client the older API that exposed AMQP 0-10 artifacts like queues and exchanges qpid::messaging the newer API that is more JMS like (even for C++) that recognized that AMQP 0-10 artifacts were not going to be part of the AMQP 1.0 spec. proton-c and proton-j part of qpid/proton qpid.apache.org/proton. These are libraries that implement the AMQP 1.0 specification. They are intended to be consumed by clients and brokers and other implementation that require AMQP 1.0 support. The project is slightly more than the libraries in that it provides some tools for developers to help them consume AMQP 1.0 including Python, Ruby, Perl language bindings. Proton Messenger API - a high level, simple but powerful wrapper on the core proton API to provide easy access to AMQP messaging. JMS implementations like Qpid proper and ActiveMQ (for example) can consume Proton. The C++ implementation in Qpid, including the broker, is planning on (has already been done I think) integrating Proton for AMQP 1.0 support. I know this doesn't answer all the questions but is this helpful? And others, did I get any of this wrong? I'm sure I've left bits out but is what I said accurate enough? William ----- Original Message ----- > Hi Mary, > Thanks for the response, unfortunately I must be a bit thick though, > cause I'm still not totally clear. > > I did take a look at the proton web site a little while back, looking > at > the link you attached it looks pretty much the same as the last time > I > looked a month or so back. But as I say the relationship between qpid > and proton is far from clear (to me at least....) > > I've just loaded up the main qpid website http://qpid.apache.org/ and > there's no obvious linkage between that and proton so that's not too > helpful. Also not helping with my confusion is that there has been > quite > a bit of traffic on the main qpid mailing list relating to work that > Gordon Sim has been doing on qpid 0.2 there seem to be quite a few > new > features in this including replacing the flow-to-disk paging with > something better, but Gordon has also been talking about adding AMQP > v > 1.0 functionality to qpid 0.2. > > So is the AMQP stuff that Gordon is talking about just about > combining > in the proton library? Will the web pages for the qpid 0.2 release > make > all this clear. > > I have to say that the proton work hasn't been especially well > publicised, I only stumbled across it by accident a month or so back > by > noticing a reference to it in the mailing list so did some digging > and > eventually found the web page - and I look at the qpid mailing list > pretty much daily. > > From your description below and from the web page it looks like > proton > is primarily a library so you'd use it in combination with something > like qpid, but is the idea that it could also be used "brokerless" so > I'm thinking something analogous to say zeromq where say one might > want > an extremely lightweight messaging IPC mechanism between processes on > the same host for example without the overhead of a full message > broker > process???? > > I noticed the proton API documentation - it looks very python centric > at > the moment, your maul below also suggests C++ but what's the state of > Java support at the moment - looks like there's a proton-j download, > how > does that relate to JMS and the qpid Java client libraries?? > > The API stuff also makes me a bit nervous - relating on to the > original > thread spawning this question. The is already *way too much* > confusion > at the moment relating to qpid::messaging versus qpid::client, more > or > less once a week someone posts to the main qpid mailing list about > that > so I think it's really important that the relationship between qpid > and > proton is spelled out clearly in a very prominent place!! It sounds > like > for the most part that the proton APIs are lower level APIs so that > for > example a client would use qpid::messaging (or JMS) and that would > delegate in the client runtime to the proton APIs, is that correct? > So > is the only time someone would actually use the proton API directly > if > one was running something embedded such as the lightweight messaging > IPC > analogy I mentioned above. > > > Sorry if I'm being a bit thick about this, but as I say I really > haven't > seen an awful lot of publicity around proton and how it relates to > qpid > so I think it'd be really good to get the documentation around the > relationships properly sorted to avoid a whole world of confusion. > > Regards, > Frase > > > On 03/01/13 20:00, Mary Hinton wrote: > > I can't answer your other questions, but did anyone answer your > > question on "What exactly is proton? > > Have you gone to the proton web site: > > http://qpid.apache.org/proton/ > > > > Qpid was built around the older versions of the AMQP protocol. > > Now that Proton is released, QPID can load the proton library and > > be AMQP 1.0 compliant. > > In the C++ code there are new AMQP projects, one for the server and > > one for the client. > > > > After you compile and build all the required libraries (including > > proton) and executables, you can use the qpidd executable with the > > following argument > > qpidd --load-module amqpd > > > > For the client you need to set up the environment variable > > QPID_LOAD_MODULE and set it to the new amqp client project name, > > e.g. amqpcd > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
