On 07/02/2014 08:24 PM, Rafael Schloming wrote:
My goal with this demo has been to explore a couple of distinct themes. The
toolkit is intended in part to illustrate how the events API allows use of
proton in a reactive programming style. It does this by building a
select/nio based Driver that functions as a simple reactor. This is useful
in its own right, however it is also intended to serve as an example of how
you can integrate proton's events into an existing selector based

Another big theme is providing the ability to encapsulate different aspects
of protocol behaviour into distinct but composable chunks. This is achieved
because the Driver dispatches each event to a configurable set of handlers.
This allows the Collector to serve as a central "event bus" and allows the
various handlers to all tie into this bus and work together to provide
useful combinations of behaviour.

I really like this composable approach, especially based on a reactive style with which it seems to fit well.

Ultimately I hope this work will address the gap that we've had between the
simple/easy to use Messenger API and the experts-only Engine API.

I personally don't think of the gap in those terms. I didn't find either of the APIs particularly simple or easy to use and I'm not convinced that the issue with the engine API was that it was intended for 'experts'

My issue with the engine API was that using it involved lots of duplicated code and the API itself was not always entirely obvious. This was less an intrinsic issue, more of a lack of focus on making it easy to use. Efforts like pyngus did a good job of closing that gap. The approach you demonstrate here shows how that could be taken even further.

My issue with the Messenger API is that I don't understand its purpose.

I believe
with a relatively small amount of work on a toolkit like this, the
internals of Messenger can be fairly trivially expressed as a composition
of different protocol behaviours, thereby allowing a simple and easy
starting point that can smoothly transition to any level of sophistication

I think this ability for users to transition for simple usage to more complex handling is very valuable. I think there is a related benefit to that approach in that it allows the API - or toolkit more properly - to evolve in a better way. Rather than an API that ring-fences the functionality, you offer a core API and a set of utilties. Different utilities can be provided for different sets of use cases. In fact another aspect I like about your demo is the example driven nature.

I would be very much in favour of refocusing proton on the engine and events API and this expanding toolkit and refining it based on a growing set of concrete examples. I think that would make proton more comprehensible and more useful. That in turn would have a positive impact on AMQP adoption.

I think it also neatly avoids the confusion with regards to existing APIs such as qpid::messaging.

Reply via email to