On 05/15/2014 01:44 PM, Ken Giusti wrote:
I think we should develop Messenger as an alternative client API to
qpid::messaging, focusing on use cases that are not necessarily well
covered by the existing qpid::messaging API. I think they
complement each other nicely.
In what way do you think they complement each other?
I think we'd be much better off if we can separate the problem spaces
these two client APIs attempt to address, and clearly communicate
these differences so that users can find the right API for their
particular use cases
That sounds neat and tidy in theory. I suspect it is not so simple in
(example: connection oriented vs message oriented).
I view that as more a question of 'style' than problem space. (I suspect
it also raises almost as many questions as it answers).
The existence of alternatives is not itself inherently problematic. What
matters is how confident a prospective adopter feels when evaluating
options for AMQP and how easily he or she would succeed if AMQP were
embraced. It's not a question of eliminating choices, its a question of
improving the experience.
I think we should take an active role in promoting this new
experimental, community-led APIs that you mentioned. To be clear,
I'm not advocating that we (QPID) _support_ them, but I think we
should add links to them directly from our QPID web site, along side
the links to Messenger and qpid::messaging.
I'm not sure what taking 'an active role in promoting' would mean, but I
confess it makes me nervous. For one thing the projects I linked to vary
widely in license, governance and maturity.
On reflection and re-reading, my post was rather rushed and confused and
the list of links was perhaps a mistake.
The central point I am trying to make, is that though there are a
variety of different *individual* initiatives, selecting an AMQP 1.0
client one can have confidence in is still not easy and it seems to me
there is no real *collective* initiative to improve this.