On 01/26/2011 07:34 PM, Alan Conway wrote:
So it seems like we have an open ended collection of concrete type
systems here:
amqp0-10
amqp1-0
amqpx-y
(stomp or whatever future protocols we support)
And we have a "generic" type system with 2 types (so far):
topic(=exchage) and queue. These are implemented in terms of whatever
concrete types are available. We want it to be easy to create objects
using the generic system, while at the same time providing "escapes" to
let the user directly create objects and tweak properties for the
underlying system if they want to. Since the set is open ended it seems
like namespaces would be appropriate here.
I see it slightly differently. I think we are talking about objects that
are in their function and purpose independent of the protocol version of
any client.
However we have inherited baggage from earlier versions of AMQP where
the protocol governing the interactions between a client and broker were
mixed up with a particular broker model. That does not mean the entities
defined by that broker model are necessarily tied to a particular
protocol version however. A queue is a queue after all. Even the concept
of exchanges and bindings need not be tied to a specific protocol.
If we follow the classic "constructor" pattern, then we should separate
identifying the type from the arguments to create an instance of that
type. The type defines the meaning of the properties so it seems a bit
murky to use a properties to determine the type.
So how about:
create(type:"topic", name:"abc", properties:{...}) - create a generic
topic using whatever underlying protocol
create(type:"amqp0-10/exchange", ...) - specify a 0-10 exchange
create(type:"stomp/foobar", ...) - specify some other protocol's object
etc.
I don't think amqp0-10 is appropriate here (I shouldn't have suggested
in the sub-type comment either). The exchange is the same for 0-8 and
0-9 as well (and the java broker supports all versions). You don't want
users to have to care about the version here. It just adds confusion.
While amqp/exchange would make more sense, I'm not convinced it is
necessary. I believe the concept of exchanges is clear and unambiguous
to those who want to think in those terms.
I think namespaces are a solution to a problem we don't have (and they
don't really solve the problem we *do* have). I'm especially
uncomfortable with tying the namespaces to specific versions of a protocol.
That leaves us open as to future type systems and gives us enough
information in the type name to determine the meaning of properties -
allowing each concrete type to define whatever set of properties with
whatever names it desires.
This also means the generic types can take a "clean" set of properties -
i.e. no "x-binding" or other protocol escapes. The generic types have a
well defined set of properties that always apply regardless of the
underlying type system - so you can write portable code.
I agree we want a 'clean' set of properties.
I don't think x-binding (or x-declare or x-subscribe) are necessary here
nor are they being proposed. Those were introduced to allow the user to
'customise' the particular interaction in interpreting and implementing
senders/receivers for a given address over a particular protocol version.
This proposal on the other hand is about the management schema that the
broker exposes in general.
I think the properties should mostly be obvious. However they aren't all
uniform between the two brokers and some are less well thought through
than others and thus more likely to be deprecated at some point in the
future.
The exchange type was a special case that seemed to me to perhaps
warrant a special name as it seemed odd to have type in the properties
as well as the object type. However on reflection that perhaps is not
such a big issue.
I'll get a list together in the next iteration of the QIP to make things
more concrete.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
