On 05/21/2014 07:32 PM, Fraser Adams wrote:
I guess that I'm fairly agnostic about there being two APIs, provided
there doesn't wind up being a competition, and that we stop at two :-)
[...]
I guess I'm slightly disappointed that the tone of this thread seems to
be that it's something of a competition, I personally don't think this
it should be and that each has a valid place. I think I'd prefer the
energy to be spent making both as good as they can be :-)
I'm sorry you are disappointed by the tone. I don't actually view this
as a competition between Messenger and qpid::messaging.
I've clearly not done a great job of expressing myself. The intent in
starting this thread was to highlight the difficulty I believe is faced
by any prospective adopter of AMQP 1.0 in selecting the API on which to
start building their applications (I could perhaps exempt those who head
straight for JMS) in the hope that an open and frank debate helps us
collectively identify ways to improve things.
I am not arguing that there is only room for one API, and certainly not
that qpid::messaging should be the only API. As a matter of fact, my
personal belief is that those two APIs are not sufficient, neither of
them being suitable for certain applications.
Choosing between the existing APIs is I think a small part of the
problem, but that is because it is not clear what limitations a given
choice imposes rather than because the choice exists.
Perhaps we've been reluctant to describe the choice in those terms
because it seems negative or because it is emphasising gaps at a given
point in time rather than intrinsic aspects of the respective designs.
However I think it is actually very important to users, and so its
perhaps useful for us to try and list the limitations, if for no other
reason than to see if there is a roadmap for resolution.
So here is an initial, non-exhaustive list of current shortcomings from
me. Please all feel free to add to and correct this.
qpid::messaging
* boost dependency
* limited to windows and linux
* requires thread per session
* can't be integrated into existing event loop
* can't handle incoming connections
* no support for transactions
* sasl support in windows very limited
Messenger
* no reconnect; no reliable way to handle it by application either
* no automatic message replay
* can't control lifecycle of links or connections (e.g. can't cancel
subscriptions or close a connection that will never be used again
without stopping the whole messenger)
* can't control source or target (can't use selectors, can't specify
dynamic node-properties, capabilities etc)
* can't set or see connection properties
* doesn't handle errors well, e.g. authentication authorisation failure,
node not found etc
* responds to incoming link attach requests by erroneously cloning
source/target, regardless of whether it understands or supports the
expectations represented
* no support for transactions
* sasl support limited to anonymous and plain
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
