On Thu, Sep 20, 2012 at 3:43 PM, Gordon Sim <g...@redhat.com> wrote: > 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. Gordon I'm not comparing the API's here. I'm comparing the *implementations of those API's*. My assumption is that the Qpid API implementation will likely use a logging façade like slf4j and perhaps some other dependencies, while the Messenger implementation will be dependency free and more compact. That is why I said the Messenger API will have a lower footprint. >> >> 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. Indeed a very valid point. I also don't have a firm opinion on this yet. I have some limited experience in exercising the Driver when writing the mailbox example but not enough to form a more qualified opinion on it's advantages and applicability in more complex situations. > >>> 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. I agree with you that there is a lot of overlap btw the JMS and Qpid API in terms of functionality and behaviour. Infact the Qpid API seems like a superset of the JMS API I also agree from a design point of view it seems cleaner. But as I said I'm not discounting either approach. It's always good to investigate all approaches and look into all kinds of factor not just technical. Until recently I have considered only option #1 (JMS --> Qpid API --> Proton, but I have heard people looking at option #2 as well. It's always good to consider all options and then choosing what the majority feels the best. As of now I don't have a firm opinion either way. I just merely wanted to lay the options on the table and initiate a discussion. Rajith > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org > For additional commands, e-mail: dev-h...@qpid.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
