Gordon, This looks really interesting. I think this is a good framework to build an extensible API to provide access to the good parts of AMQP (flow control, exactly-once with recovery, transactions, etc., etc.).
Would you consider contributing it to the Proton project, perhaps as a branch or a contrib so others can get involved? What is the tool you use to create the tutorial code examples? -Ted On 07/31/2014 06:52 AM, Gordon Sim wrote: > Following on from the approach taken by Rafi in his demo of the new > event support in the proton engine, I've sketched out a few examples for > common 'client' scenarios using the proton engine and a 'toolkit' of > useful event handlers and utilities. > > The idea behind this is to explore whether this approach is feasible as > a general purpose API. It is a reactive style of programming, and is at > present fully asynchronous/non-blocking. > > Many more examples are need to ensure all aspects are fully considered, > but I think there is enough there to give an idea of the approach that > we can then discuss and refine collectively. (Clearly the toolkit could > also be expanded to cover higher-level and richer concepts as well). > > The Qpid Messaging API would remain, but Proton would be an alternative, > particularly suited for fully asynchronous applications with the full > power and flexibility of the engine where needed, but with the common > cases made simpler. > > I've focused on python, but I think the approach could be extended to > other languages. There is a little bit of 'tutorial' style text to > introduce the examples (some reference documentation around the added > utilities would also be needed): > > http://grs.github.io/proton_examples/html/ > > and the examples and utility code (some of which are based on Rafi's > demo code) needed to run them is here: > > https://github.com/grs/examples > > I think this looks like a promising approach to make proton more > understandable and usable, improve AMQP adoption and get consensus on a > clearer roadmap as far as Qpid APIs is concerned. However as always I'm > eager to hear your thoughts! Don't hold back on criticism or voicing > disagreement, it is better to have a frank conversation. > > --Gordon. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
