On 25 June 2012 19:33, Rajith Attapattu <[email protected]> wrote: > On Mon, Jun 25, 2012 at 1:26 PM, Gordon Sim <[email protected]> wrote: >> On 06/25/2012 05:37 PM, Rob Godfrey wrote: >>> >>> when we are talking about Qpid Proton, it may be >>> integrated in the (imaginary) XXXMQ broker, and XXXMQ's relationship >>> to Qpid Proton and the Qpid Proton discussion lists should >>> (theoretically) be the same as that between Qpid Java/C++ Broker and >>> Qpid Proton. If we mix these lists up it makes is much harder for the >>> (imaginary) XXXMQ community to view the Qpid Proton lists as equally >>> applicable to them >> >> >> I think another way of putting this is that a distinct list helps reinforce >> the notion that the proton is an independent artefact in its own right, with >> public APIs and appropriate guarantees around stability and focus rather >> than just an internal layer subservient to some of the other Qpid >> components. >> >> That seems reasonable. >> >> However the new site describes proton as "suitable for simple clients or >> high powered servers" and "ideal for building out your own messaging >> applications". I think it is important to address the overlap with the >> existing user list in some way and to anticipate the questions this may well >> raise for users (and indeed developers!) of our existing messaging APIs as >> well as those who become interested in the community in the future. > > This is indeed a very good point. > End users might wonder which API to use. The high level Qpid API or > the API given by Proton. > Therefore as Gordon says we need to clearly communicate the "intended > audience" for these API's and the pros and cons surrounding them. > > This will prevent people from choosing the wrong API due to misconceptions. > For example that proton somehow gives more flexibility or power to the > application developer bcos it's perceived to be more closer to the > protocol than the Messaging API etc.. > We had a similar situation with the old java client, where some end > users thought the low level classes were better than using the JMS > interfaces as it gives more flexibility etc.. > > We may very well have a similar situation on our hands. So we need to > get the message right !
I'm not sure that there is an overall write/wrong API to use... what is important is that we properly define APIs, document them and then support them. We should definitely be aiming to avoid creating "competing" APIs within Qpid. So far we have seen low level APIs that are comprehensive, but not necessarily user friendly (e.g. the proton engine API), high level externally defined APIs (such as JMS, WCF), and our own attempt to build user friendly but powerful APIs (the messaging API). On top of proton there's also been some work at producing a simplified API which is at a higher level that all of the APIs above and may not expose the full set of functionality. I think that that gives something like "Simple" < "Comprehensive" < "Low Level" as three levels of APIs, with "standard" APIs hanging off these where it makes sense to build them. -- Rob > > Rajith > >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
