Proton Java Messenger API questions

[Steve Huston <sh...@riverace.com>]

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?

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

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. 


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org

Re: Proton Java Messenger API questions

["Gibson, Jack" <ja...@paypal.com.INVALID>]

+1

Jack Gibson





On 1/26/15, 4:38 PM, "Steve Huston" <sh...@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?
>
>Does API stabilization include some type of fatal error handling in the
>Messenger API?   
>
>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.
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>For additional commands, e-mail: users-help@qpid.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org

RE: Proton Java Messenger API questions

[Steve Huston <sh...@riverace.com>]

Great - thanks very much for the quick reply and explanation!
-Steve

> -----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 <sh...@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

Re: Proton Java Messenger API questions

[Rafael Schloming <rh...@alum.mit.edu>]

On Mon, Jan 26, 2015 at 5:38 PM, Steve Huston <sh...@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