On 01/21/2011 07:18 PM, Jonathan Robie wrote:
I think I'd like to be able to declare the objects we currently support
directly. That includes AMQP 0-10 and the Qpid extensions.
I'd rather not have a declaration mix constructs from two different
semantic domains unless there's a clear advantage to doing so. So I'd
like to be able to say "create direct exchange", not "create direct topic".
The request to create a direct exchange would be something like:
create (type:"exchange", name:"abc", properties: {"sub-type":"direct",
"durable":True})
If the sub-type property is omitted, the default is a topic exchange. E.g.
create (type:"exchange", name:"abc", properties: {"durable":True})
I'm not sure whether 'sub-type' should be the *actual* name for the
property here. Perhaps something a little more explicit and specific
would be clearer, e.g. x-amqp010-exchange-type. The counter-argument
perhaps is that sub-type could be more generally useful e.g. in allowing
one to specify a ring queue or a last-value queue and uniformity might
be helpful. TBD in updated draft.
Do we need to allow the user to declare Messaging API topic?
Yes, I believe that is desirable. If I want to send to a queue, I could
have a setup script that issued a create request for an object of type
queue. If I want to do the same for a 'topic' (as in JMS or in the
messaging API) then it would be nice to be able to simply issue a create
request for the appropriately named topic.
E.g. an alternative form of the above request would be:
create (type:"topic", name:"abc", properties: {"durable":True})
If so, adding 'create topic' is easy,
Indeed. A topic as interpreted in the current implementation of the
messaging API (or indeed our JMS implementation) is based on an
exchange. Hence the suggestion to recognise 'topic' as an alias for an
exchange (and to default to topic exchanges, which is what the
addressing scheme does also).
Pub-sub topics are a common and well understood pattern. In future we
may want to offer more explicit support for them.
(The pre-1.0 amqp exchange types on the other hand should be considered
optimisation hints in my view, since the only thing they achieve is
specialised implementations of particular matching patterns).
[snip]
Do we want to be able to support other messaging models other than AMQP?
Do you have anything specific in mind here?
What happens if two different systems use the same name for different
things?
I think we would need to consider such questions on a case by case basis.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
