qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gordon Sim <g...@redhat.com>
Subject Re: events work and demo (How to implement your own broker in < 100 lines of code)
Date Mon, 07 Jul 2014 13:06:58 GMT
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
> implementation.
> 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
> desired.

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.

To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org

View raw message