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.
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.