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 11:40:52 GMT
On 10/09/2013 12:10 PM, Rob Godfrey wrote:
> On 9 October 2013 11:24, Gordon Sim <gsim@redhat.com> wrote:
>> On 10/08/2013 03:42 PM, Rob Godfrey wrote:
>>> The second case of defining some namespace pattern within the broker
>>> wherein any unrecognized names will lead to node creation seems like a
>>> broker specific feature with no need (or requirement?) for
>>> standardisation.
>>> Am I missing something here?
>>>
>>
>> I personally much prefer the second approach. Its simpler and more
>> flexible for broker implementers to do in different ways (according to
>> their existing configuration mechanisms and details of the way their code
>> already works). It also takes the 'decision' out of the client, which seems
>> preferable from a 'philosophical' pint of view, and means that client
>> libraries need not be affected.
>>
>>
> But whether an attempt to send to/receive from an address which does not
> exist should result in either a failure or the creation of a new node is
> not just a broker/service concern - I'd actually think that it was an
> application (and therefore client) concern.

I agree I think it is an application concern, but I see it as a 
deployment/configuration concern, rather than a development concern. 
Being able to control that entirely through broker configuration is 
valuable.

>> I'm certainly not suggesting any official 'standardisation'. I'm merely
>> hoping to find a simple, practical, 'bottom-up' consensus that would make
>> switching between AMQP brokers easier for users.
>>
>> If more brokers were to support some way of having nodes created on demand
>> purely based on broker side configuration (the details of which would be
>> broker specific), that would in my view be useful to anyone looking to try
>> out applications against different brokers.
>>
>> As such, I'm keen to implement something like that in qpidd and would also
>> be keen to start talking to some of the other broker maintainers to see if
>> I could persuade others to do the same (if they have not already).
>>
>>
> So while I don't object to brokers doing this, I'm really not keen on
> trying to use names to identify the properties of nodes to be created

If you mean the address of the node, then I agree with you. I'm not keen 
on that and mentioned it merely as what is currently relied on in the 
absence of anything else.

Hence my preference for capabilities, which is a defined extension point 
that clearly (in my view) fits this situation quite well and can be used 
whether or not the node is to be dynamically created and orthogonal to 
any naming scheme for the node itself.

[...]
>>> Yes, we need to define what node-properties terms like "queue" and
>>> "topic"
>>> actually mean.
>>>
>>
>> The two sentences above attempt to do that in a minimal way. To me they
>> capture the essential capabilities that people expect when thinking of a
>> queue or topic. I would of course be eager to here alternative suggestions,
>> whether it be entirely different mechanisms, or just different capability
>> names or descriptions. That's the purpose of the original email really.
>>
>>
> So as above I'm pretty negative on just using names

Again, I'm *not* proposing using *node* names to indicate the type of 
node, I'm proposing using named *capabilities*.

The distribution mode gets close, but is not quite adequate. Since I 
think 'queue' and 'topic' are basic capabilities for a source or target 
that would are supported by all current brokers and reasonably well 
understood, that is what I suggested.

[...]
>> I wouldn't want to tie consensus on a very simple thing to a larger more
>> comprehensive standardisation effort for management. Neither would I want
>> to get in your way there however. If you have different names or
>> descriptions that would align better with what you are doing, please feel
>> free to suggest them.
>>
>>
> But I wouldn't want to define a "simple" thing that (potentially) conflicts
> with the work that is being done through the official standards, or gives
> the impression of a standardisation which in fact is not standard.

All I'm suggesting with named capabilities is exactly what has been done 
for filters already.

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


Mime
View raw message