qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gordon Sim <g...@redhat.com>
Subject Re: AMQP 1.0 and creating nodes on the fly
Date Wed, 09 Oct 2013 14:14:02 GMT
On 10/09/2013 01:25 PM, Rob Godfrey wrote:
> OK - I think I'm confused as to what you are proposing then.  I thought you
> were looking for a way to standardise without client libraries having to
> send properties / capabilities.
> Perhaps it would be helpful to write out what you are thinking in some sort
> of pseudo code or something?  There are obviously a lot of different places
> that capabilities exist and a lot of different names.  I can now no longer
> tell if we are agreeing, disagreeing or talking about completely different
> scenarios :-)

My apologies! I think I included too many different points in my 
original email with the intention of adding some context.

I'm really making two separate proposals:

(1) I propose to add a mechanism to the 1.0 support in the Qpid c++ 
broker to allow nodes to be created on demand through broker 
configuration alone. Though the details of this would be different from 
ActiveMQ and ApolloMQ, the same behaviour would then be available if 
configured, which would aid in moving applications between these. As 
part of this proposal, I would also then see if I can persuade other 1.0 
broker implementers to offer something similar (with the understanding 
that the details of configuration will all be different[1]).

(2) The second proposal is to try and get agreement on two capabilities 
that describe the basic functionality of 'queues' and 'topics' as 
commonly understood (e.g. as described by JMS).

A 'queue' capability implies that message will (by default) be 
distributed between competing consumers (i.e. it supports a distribution 
mode of 'move' by default, though it may also support 'copy' and behaves 
as a 'distribution node' as described by section 3.3 of the spec) and 
will be stored pending the availability of a consumer to deliver it to.

A 'topic' capability will distribute messages to all interested 
subscribers, i.e. non-competing consumers, i.e. a distribution mode of 
'copy' and unless it offers some caching/reply capability (which I'm not 
concerned with here), it would drop messages for which there were no 
interested subscribers.

These capabilities could then be requested and/or advertised in the 
source/target of an attach to indicate the sort of basic behaviour 
expected or provided by a node.


[1] E.g. one broker might have a simple broker wide toggle as to whether 
nodes are created on demand or not, one might provide a way to define 
policies that match by name and determine whether they can be created on 
demand or not, another might create on demand by default unless 
restricted through permissions etc.

To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org

View raw message