Gordon Sim wrote:
Alan Conway wrote:
On Wed, 2009-04-15 at 15:37 +0100, Gordon Sim wrote:
I don't see view this work as replacing the existing API. I think it
is simply at a higher level of abstraction.
I see a role for a 'mid-level' API that provides full access to what the
protocol can do, without being tied to the protocol details.
That's pretty much what I am aiming for also. We probably need to dig
into some specifics to understand the different approaches we each have
in mind.
The 0-10 specific API will still be supported and can I think be
considered stable. The initial implementation of the higher level API
I sketched out uses the 0-10 specific API that we have almost without
change.
So are you thinking we'll implement the 0-10 API over the 1.0 protocol?
No.
I'd rather we get a more "neutral" API that's close enough to cover
everything the protocol can do, but not tied to individual protocol
commands.
So you feel that my initial proposal is not close enough to allow
applications to exploit particular aspects of the protocol? What sort of
things are you thinking of there? There may well be something missing;
it may also just be the incompleteness of the sketch.
Partly that - we need to cover flow control, Futures etc. Partly it's a vague
worry that defining "high level" patterns of use may not provide access to the
full power of the broker. A lot of AMQP's flexibility comes from allowing the
users the freedome to create and bind queues and exchanges (even more so in 1.0
where its easy to compose "links" into networks).
So I'm all for easy to use patterns for the common cases, but I think we still
may still need to provide some more direct access to the notion of
linking/binding (and to do it in a way that works for AMQP 0-10 and 1-0)
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org
