On 10/09/2013 12:10 PM, Rob Godfrey wrote:
On 9 October 2013 11:24, Gordon Sim <[email protected]> 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: [email protected]
For additional commands, e-mail: [email protected]
