qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Godfrey <rob.j.godf...@gmail.com>
Subject Re: AMQP 1.0 and creating nodes on the fly
Date Wed, 09 Oct 2013 12:25:13 GMT
On 9 October 2013 13:40, Gordon Sim <gsim@redhat.com> wrote:

> 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.
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 :-)

-- Rob

> [...]
>  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<users-unsubscribe@qpid.apache.org>
> For additional commands, e-mail: users-help@qpid.apache.org

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message