On Tue, Jan 7, 2014 at 3:24 PM, Rob Godfrey wrote:
> On 20 December 2013 19:49, 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.
>
>
> It might make it easier for you (since you have a complete view of every
> piece of the code and design) - for myself I found that it made things
> *much* harder, as tests were running through multiple layers rather than
> being isolated to a single component. When a test "failed" it was entirely
> unclear which layer the failure resided in or even why the outcome should
> be as the test expeted. Personally I'd say the testing is a strong
> argument for separation (although it means more work upfront it makes it
> easier for everyone in the long run).
>
I'm not suggesting messenger tests are in any way a substitute for API
tests against the engine itself, rather that are other important categories
of testing, e.g. soak testing, that would require building something that
is pretty much equivalent to what messenger already does.
>
>
> > 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.
>
>
> Every other project that wants to use the Proton engine will also be
> writing tests for their use of the API. And they'll have different use
> cases and different pattern that may not be something supported by
> Messenger.
>
> Sure, it's great that Messenger tests will implicitly test the Engine, but
> they are not a substitute for Engine tests.
>
As I said above, I don't believe we have been using them as a substitute
for engine tests, rather they are a tool for discove
