qpid-proton mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ted Ross <tr...@redhat.com>
Subject Re: improving cross language maintainability
Date Mon, 23 Dec 2013 20:39:01 GMT

On 12/20/2013 01:49 PM, Rafael Schloming wrote:
> On Fri, Dec 20, 2013 at 11:43 AM, Fraser Adams <
> fraser.adams@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

View raw message