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.
--Gordon
[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-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org
