Great - thanks very much for the quick reply and explanation! -Steve
> -----Original Message----- > From: Rafael Schloming [mailto:r...@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 <shus...@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
