On 2. 07. 14 21:24, Rafael Schloming wrote:
Hi Everyone,
Apologies for being a bit quiet recently. I've been heads down working on
some improvements to the events API. I've put together a little demo that
showcases what I've been doing.
I like it!
One question on opening up the events API a bit more:
Our project has a libdispatch based driver for proton (C equivalent of
proton-hawtdispatch)
and the collector has greatly simplified tying together top and bottom half.
One area where I feel my interface between my top and bottom abstraction
could be futher simplified is
if the driver could inject socket related events (connection down,
connect completed, ...) into the same
collector. Even just one event type would suffice, I can then
interrogate the driver what happened.
Currently I have two callbacks in the driver, one for 'there are
events' and one for 'there are socket issues'
Do you feel such a thing would be of use in general? (or maybe there
already is such a thing, but I missed it)?
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 can say that writing the top half on top of engine consisted of
copying quite large chunks
of messenger connection, session and link setup logic with only minor
tweaks, so having
reusable pieces here sure sounds interesting.
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 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.
Sorry for the long spiel. Please have a look and let me know what you think.
IMHO it'd be good if there was more than one user of said components
than just Messenger
or their interfaces can quickly get too Messenger specific. One concrete
area are threading
assumptions between independent engine instances in connection oriented
architectures
which are in contrast with Messenger single-threaded approach over
several connections.
Regards,
Bozzo
