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
