reactor/container update, and 0.9 release update

[Rafael Schloming <rh...@alum.mit.edu>]

Hi Everyone,

As promised here is an update on the status of the reactive API work (both
reactor and container). I'm also adding a 0.9 release status since it is
related. If you don't care about the details of the reactive API work then
skip to the end for the release details.

For the reactive API work, first off I want to reiterate that the reactor
work is intended to complement Gordon's work, not compete with it. What
I've developed in C is essentially a port of the same style of reactor that
Gordon has developed in python. The python Reactor class is the swig
wrapped python binding for the C reactor implementation.

The goal here is that Gordon's Container class can simply extend Reactor
and rely on the C implementation for all the core event processing and
dispatch. This will hopefully simplify the implementation of Container, as
well as allow handlers in C and python to work seamlessly with each other.
This ability actually opens up some very powerful and exciting new
possibilities, but I'll spare you the details for now.

The API and examples Gordon has built out should remain largely (perhaps
entirely) unchanged by all this. Gordon is working a couple of patches to
get this to work as advertised, but I believe we are almost there.

Speaking of examples, I should clarify that my intention with the reactor
examples is to supply a kind of tutorial on how the core event processing
model works, covering things like how to schedule a recurring task, perform
blocking file I/O, integrate external fds into the I/O loop, replacing the
I/O loop, debugging the event stream, and also how to use delegation
between handlers to break up your application into smaller cooperating
components, as well as to leverage our library of existing components. This
category of stuff isn't intended to be the top level "hello world" for
proton, but rather what you would go to after you've got your top level
hello-world up and running and you need build a more complete mental model
of how the core processing works in order to develop/debug your modified
helllo-world into a more comprehensive piece of software.

The way the examples are structured right now might not make this entirely
obvious. I think pulling Gordon's examples up to the top level might help
clarify things a bit, as these are really the first ones I'd expect you'd
want to look at, and then the reactor sub-directory would be where you'd go
for the deeper dive into the sort of stuff I mentioned. This would also be
consistent with Justin's suggestion around removing the term "engine" from
the package namespaces.

My hope is the last few details of all this will drop into place in the
next few days, at which point I think we'll be all set for 0.9 alpha 3.

Hopefully this helps clear up any confusion, but please follow up with any
questions.

--Rafael

Re: reactor/container update, and 0.9 release update

[Gordon Sim <gs...@redhat.com>]

On 02/12/2015 02:01 AM, Rafael Schloming wrote:
> I think pulling Gordon's examples up to the top level might help
> clarify things a bit, as these are really the first ones I'd expect you'd
> want to look at, and then the reactor sub-directory would be where you'd go
> for the deeper dive into the sort of stuff I mentioned.

Suggested change: https://reviews.apache.org/r/31090/

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

Re: reactor/container update, and 0.9 release update

[Gordon Sim <gs...@redhat.com>]

On 02/12/2015 02:01 AM, Rafael Schloming wrote:
> For the reactive API work, first off I want to reiterate that the reactor
> work is intended to complement Gordon's work, not compete with it. What
> I've developed in C is essentially a port of the same style of reactor that
> Gordon has developed in python. The python Reactor class is the swig
> wrapped python binding for the C reactor implementation.

The work I did was focused at getting examples to demonstrate a simple 
yet fully functional api. The eventloop was a necessary means to achieve 
that, but wasn't itself the primary driver (which was improving the 
usability and providing examples).

I now have the examples and the container they depend on working on top 
of the reactor and will commit the necessary changes shortly. The 
container simply provides some convenience methods for establishing 
connections and links, it is not an alternative api. Similar to the 
handlers it can be used if and when useful, but doesn't lock you in to 
doing so for everything.

[...]
> The way the examples are structured right now might not make this entirely
> obvious. I think pulling Gordon's examples up to the top level might help
> clarify things a bit, as these are really the first ones I'd expect you'd
> want to look at, and then the reactor sub-directory would be where you'd go
> for the deeper dive into the sort of stuff I mentioned.

That is a good idea. I'll do that once I get all the changes committed.


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