One goal behind this thread was to get ideas on how to answer these questions coming from a new user. So thanks a lot for your answers. I've had the privilege of speaking to Rafi several times, so I had a fair bit of knowledge on each of those questions.
These are the sort of questions a prospective user would have. >From past experience pointing people at examples or a header file to figure out the API hasn't been great. I'm not insisting we should do things one way or the other, but wanted to have a discussion to see what peoples thoughts are on the $subject. My opinion is that some sort of a document that describes the API (and perhaps and FAQ) could be quite useful. Otherwise we will be getting a lot of queries from end users and testing folks about what the correct behaviour is. Rajith On Thu, Sep 20, 2012 at 5:18 PM, Darryl L. Pierce <dpie...@redhat.com> wrote: > On Thu, Sep 20, 2012 at 03:37:10PM -0400, Rajith Attapattu wrote: >> Given some of the recent discussions, it appears there isn't much >> consensus as to what the "Messenger API" is. >> For my own sanity, could someone with more knowledge on the $subject >> please explain the following? >> >> 1. What is Messenger API ? >> i.e Do we have a doc or a wiki page that documents what the API >> is and more importantly what the expected behaviour is. > > From my perspective, a Messenger is a high-level end-point for sending > and receiving messages. It keeps you from having to worry about the > underlying components of a session, a context, encoding and decoding > messages. Instead, it gives you very simple APIs to start and stop > communications, queue up and send messages and receive and then pull out > individual messages for processing. > >> 2. How is it different from the "Messaging API aka Qpid API" >> I'm looking for something more than the matrix given by Rafi, all >> though it provides a good start to understanding it. > > Again, from my perspective, it reduces the complexity by, again, keeping > you from having to worry about the details of connecting with a remote > messaging endpoint. > > Something else is that it's designed from the ground up with efficiency. > One specific one that comes to mind is the pn_messenger_get() API, which > can reuse existing instances of pn_message_t to avoid spending time > allocating memory. > >> 3. How are we planning to position these various API's in the future? >> I agree that a lot of things are up in the air, but it's also good >> to share some early ideas all though they might change in the future. > > My understanding is that we'll have a layer on top of Proton that will > provide the existing Qpid APIs while, underneath, Proton is doing the > heavy lifting. > > I may be wrong on some (or all) points, in which case someone please set > me straight. > > -- > Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc. > Delivering value year after year. > Red Hat ranks #1 in value among software vendors. > http://www.redhat.com/promo/vendor/ >
