On 09/09/2014 03:59 PM, Alan Conway wrote:
On Mon, 2014-09-08 at 19:07 +0100, Fraser Adams wrote:
Messenger gurus seem to be keeping their heads down a bit.
Is it *really* just Alan and I who are interested to understand the
error handling/reconnection behaviour of Messenger?
Is anybody using it in "industrial strength" applications or is it just
being used in quick and dirty demos? Without error handling and
reconnection mechanisms I'm struggling to see how it can be used for the
former.
I can likely hack things and Alan also mentioned that he "cheats", but
I'd really like to know from people who really understand messenger how
to do it *properly*.
I've been looking at this and error handling in Messenger is not just a
matter of fixing implementation, there are some pretty big API questions
to be answered about when and how you can report errors. Its not
unfixable but I'm starting to think about moving away from Messenger and
towards using the proton Engine API.
The original tradeoff was that engine is more complete and flexible but
harder to use, whereas Messenger is easy but not as complete/flexible.
However if you look at the toolkit & examples at
https://github.com/grs/examples
it makes engine a lot more appealing.
This work has now been moved to a branch in proton's svn:
https://svn.apache.org/repos/asf/qpid/proton/branches/examples/tutorial/_build/html/tutorial.html
examples themselves are in:
https://svn.apache.org/repos/asf/qpid/proton/branches/examples/tutorial
I'm working on a slightly more involved example at the moment which I'll
hopefully be in a position to check in before too long.
I should also point out again that these examples originated from Rafi's
demo of the event oriented use of proton
(https://github.com/rhs/qpid-proton-demo) which also show how features
such as those offered by Messenger (routing, connection management) can
be built as more composable utilities along the lines Alan describes below.
The idea is to provide blocks of
"normal default" behavior in a toolkit to get going quickly (and to keep
you going for many/most uses) but allow those to be modified or replaced
as things get more complex. The nice thing about this is that you know
you can peel back the toolkit if you need to and get full access to the
proton event machine, so anything proton knows you can react to.
If we can make the engine API approachable enough for general messaging
use (while keeping it powerful enough for integration use) then it might
make more sense to focus on doing that than on maintaining two different
APIs for proton.
I very much believe it would.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org
