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 practice.

(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.

Reply via email to