qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rafael Schloming <...@alum.mit.edu>
Subject Re: Proton Java Messenger API questions
Date Tue, 27 Jan 2015 03:49:59 GMT
On Mon, Jan 26, 2015 at 5:38 PM, Steve Huston <shuston@riverace.com> wrote:

> Hi,
> I have a customer working on some development and trying the Proton Java
> Messenger API. They're having some problems and sent along the following
> questions. Could someone please help clarify these issues?
> Thanks,
> -Steve
> The roadmap is at a pretty high level.   Any insight on what API
> stabilization means?

Once Proton hits 1.0 I'd like to guarantee ABI stability (and API
compatibility) for the entire 1.x series. This is basically a bucket for
things to fix prior to that point. Off the top of my head, things that fall
into this bucket inculde:

  - removing deprecated/unused APIs (the driver, some of the more ancient
message codec routines)
  - removing some useless duplicate structs
  - making sure internal headers are not publicly accessible
  - streamlining usage of the codec API
  - streamlining sending/receiving messages

> Does API stabilization include some type of fatal error handling in the
> Messenger API?

API stabilization is really about locking down the core APIs and making
sure we can commit to the ABI/API for long enough to justify a 1.x series.
Messenger's error handling doesn't really fall into this bucket. That's not
to say it won't happen, though.

> Going forward is the Messenger API going be the primary API or will most
> applications need to write directly to the lower levels (engine,
> transport...)?
> As it stands the Messenger API's lack of error handling (silent failure
> and continued operation under failure conditions) really makes the
> Messenger API unusable for real applications.

Going forward, my plan is to reconcile Messenger with the Reactor API. I
believe by doing this we can provide a much better model for non blocking
use of messenger than the current API provides. I also intend to rework the
internals of messenger to operate as a set of cooperating handlers which
can be made accessible to applications, thereby allowing much more
flexibility and customization of a given messenger's behavior. The events
framework should also provide a strong basis for doing proper error
handling, and the timer system should make certain higher level features
like automatic reconnect possible.

At its inception, Messenger's goal was to provide a very simple interface
for sending and receiving AMQP messages that doesn't require understanding
many more concepts than just "message" and "address". I still believe this
is a very important goal, however where the current Messenger API has
fallen short is in the ability to easily transition people to some of the
more advanced scenarios available to them with AMQP. I believe the above
design can address that shortcoming, so that is where I've been focusing my

I know this doesn't directly answer your question of whether it will be
"the primary API", but my hope is to make that question kind of moot by
making transition between the messenger portion of the API and the rest of
the API smooth enough that you don't really need to choose up front which
approach to use. You can just do what is easiest for your initial use case
and if you need to tweak something at a lower level or provide some aspect
of higher level functionality, that will be easy to do.

Initially I'm doing all this on the C side only simply because it involves
a fair amount of exploratory coding and design work and doing that in two
languages simultaneously is not very efficient at all. Once the design is
in place though, I believe it should be significantly less work to provide
the same sort of thing in Java.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message