On 12/20/2013 01:49 PM, Rafael Schloming wrote:
On Fri, Dec 20, 2013 at 11:43 AM, Fraser Adams <
fraser.ad...@blueyonder.co.uk> wrote:

I've been following this thread with interest and I guess that Rob's
comment


"

However I think that would require us to be
organised differently with a recognition that the Engine and Messenger are
conceptually separate (with Messenger depending on the Engine API, and
having no more authority over defining/testing the engine API than any
other client
"

Struck some resonance.

I think perhaps the layering is OK if you're familiar with the code base
and perhaps it's more about "packaging" than layering, but FWIW coming into
proton quite "cold" it seems like messenger and engine are essentially
"combined". Now I know that's not the case now from the responses to my
"how does it all hang together" question of a few weeks ago, but in terms
of packaging that's still kind of the case.

So what I mean by that is that qpid::messaging and proton messenger are as
far as has been discussed with me "peer" APIs - both high level that can
achieve similar things albeit with different semantics, whereas engine is a
lower level API.

Why is it in that case that the proton library is built that contains both
messenger and engine? OK, so it's convenient, but as far as I'm aware
neither qpid::messaging nor Ted's dispatch router actually use messenger at
all, they both use engine? That would suggest to me that engine and
messenger probably ought to be exposed as separate libraries? (and
presumably there's a similar position in Java where the JMS implementation
is engine not messenger based - though I've not looked at the jar
packaging).

I guess (perhaps related) it just might be better if messenger was in a
separate source tree, which I'd agree might be a faff, but would clarify
the hierarchical rather than peer relationship between messenger and engine.

So I guess that my take is that Rafael is perfectly accurate when he says
that "I believe they are currently layered precisely the way you
describe" that certainly seems to be the case at the logical level, but at
the "physical" level it's an awful lot less clear of the layering -
certainly from the perspective of a novice trying to navigate the code base.

There is certainly a pragmatic element in keeping messenger and engine
bundled the way they are. From a development perspective, having messenger
in the same code base makes testing significantly easier. Writing a simple
command line program to fire off a few messages in order to reproduce some
scenario is quite trivial with messenger, but would involve lots of boiler
plate with just the engine directly. That's something I would like to work
on improving about the engine API, but it is very slow and difficult to
make changes given the current setup I described in my original post. Given
that, realistically I think if we were to pull messenger into a separate
code base, there would be multiple sources of duplicate effort, not only
having to duplicate/produce another non trivial multi lingual build system,
but we would also need to build up a test harness that duplicates a good
chunk of what messenger already does. Granted a chunk of that is
boilerplate that should be somehow refactored into the engine API proper so
that it is easier to use in general, and if this were to happen such a
split would probably be more feasible, but that kind of refactoring is
really prohibitively expensive given all the different shims and bindings
that would be impacted.

I'd also point out that from a user perspective I think there is some
synergy in bundling a higher level tool together with the engine. It is
very rare that you are going to want to embed the engine in something and
not want some convenient high level way to send that thing a message. Case
in point, Ted's dispatch router proper doesn't actually use messenger as
you say, however he ships it with several command line scripts that do use
messenger. Splitting them up would result in both him and his users having
to deal with an extra dependency.

This is true. The system tests in the Dispatch test suite are also built on Messenger. I think Messenger is sufficiently lightweight that there's no issue with it being bundled with Engine. The separation I'm more interested in is Messenger+Engine and Driver. I would like to see it be easier to use alternate drivers for Proton-based software.


I'd have to agree also with Rob about the horizontal scaling aspects of
lack of comments and documentation, particularly with respect to engine.
I'm currently trying to get a JavaScript_messenger_  working because that
seems tractable given the examples and documentation around messenger
(though as you know even there I've had a fair few complications) my
personal preference/familiarity is however around the JMS/qpid::messaging
API and I'd ultimately quite like to have a JavaScript "binding" for that,
but at this stage I wouldn't know where to begin and I'd probably end up
"reverse engineering" the work Gordon has done with qpid::messaging and/or
Rob and co. are doing with the new JMS implementation.

I'd be interested to hear from Gordon and Ted about how they went about
building capability on top of the engine API.

I hope I'm not coming across as over-critical - email is a bit rubbish at
conveying emotion :-) I guess that I just want to add my 2p from the
perspective of someone coming in new with no previous exposure to the code
base, which is hopefully a fairly objective position.

No worries, I'm well aware of the issues you mention and I'm as eager to
see a solution as anyone else. I kicked off this thread asking for thoughts
and ideas, so I certainly can't blame anyone for speaking up.

--Rafael


Reply via email to