qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Huston <shus...@riverace.com>
Subject RE: Proton Java Messenger API questions
Date Tue, 27 Jan 2015 16:58:51 GMT
Great - thanks very much for the quick reply and explanation!

> -----Original Message-----
> From: Rafael Schloming [mailto:rhs@alum.mit.edu]
> Sent: Monday, January 26, 2015 10:50 PM
> To: users@qpid.apache.org
> Subject: Re: Proton Java Messenger API questions
> 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 efforts.
> 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.
> --Rafael
View raw message