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 ! 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]
