On 09/20/2012 08:16 PM, Rajith Attapattu wrote:
On Thu, Sep 20, 2012 at 2:36 PM, Gordon Sim <g...@redhat.com> wrote:
However I am curious as to what dependencies and/or restrictions the Qpid
messaging API imposes? Also what precisely you mean by footprint here and
why the Messenger API would necessarily have a lower footprint?
I can't think of any jvm level restrictions on the Qpid API if done correctly.
But I suspect we will use log4j at the least as an external dependency.
However I agree that we could make a concious effort to ensure we
don't use any dependency even at this level.
(Ex by using jdk logging.)
That seems orthogonal to the API. Either you offer configurable logging
in the implementation or you don't; either you roll your own or you don't.
If we do so then I see no difference or special advantage of the
Messenger API over the Qpid API.
From an API perspective I don't think think one is better than the
other. They both seem to have their applicability.
By footprint I was referring to size in bytes from the dependencies.
My answer for based on the assumption that the Qpid API implementation
will have one or more deps.
Other than logging what dependencies do you foresee? Would they be in
support of functionality required by the messaging API by not by the
messenger API?
In your original point on the two routes to 1.0 support in JMS (not
forgetting of course that 0.18 already has full JMS support over AMQP 1.0,
verified both against the Qpid java broker and SwiftMQ), you have 'Proton'
as the base in both cases but don't say specifically which part of it you
mean - I assume you mean the engine?
I believe we have two options there as well.
1. Use the engine
2. Use engine + driver
Which is more applicable is debatable at this point.
I haven't thought much about it yet, so don't have an opinion yet.
Yes, I was counting both of these variations as engine based
implementations.
I wouldn't consider my point of view at all firm on this, but I would it
seems to me that there are already IO frameworks in Java and it would be
worth looking at some of those before going ahead an implementing
something new. Specifically we should be clear on what we gain by (to
some extent) reinventing the wheel there.
If so, the one observation I would offer is that the bulk of the work needed
for something like the API currently available in c++ in the qpid::messaging
namespace would be required there anyway. It is after all very similar in
style to JMS without the issues mentioned above. My instinct is that having
an explicit interface somewhere between the JMS and Proton Engine APIs will
actually contribute to a cleaner simpler implementation.
The question then seems to me whether there is value in exposing that
interface, and offering user the option of avoiding the limitations imposed
by JMS without loss of functionality and keeping a similar style. I myself
believe there is.
The Messenger API, at least as I understood it, was to be for the simplest
use cases. Would a more fully functional API without the baggage of JMS but
offering similar (indeed a little expanded) level of functionality not be
valuable? I myself believe it would.
If we did chose option #2, I wasn't suggesting we shouldn't have a
Qpid API implementation.
In that case we could have,
JMS Client --> Proton
Qpid API --> Proton
The downside for the above approach is possible duplication of code.
A possible advantage could be that each implementation could be very
focused and evolving the Qpid API will not impact the JMS
implementation.
In terms of focus, I do honestly believe that they would require very
much the same code in both cases. The central pattern is the
coordination between (an) application thread(s) and (a) io/driver
thread(s). The functionality is also similar - optionally sync or async
publication, prefetched, server-pushed subscriptions and client-pulled
receivers, acknowledgements etc.
Again I suspect that even if you didn't expose the interface, having it
explicitly defined as part of the internal architecture would lead to a
cleaner solution overall.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
