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.


On Thu, Sep 20, 2012 at 5:18 PM, Darryl L. Pierce <> 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.

Reply via email to