On 9 October 2013 13:40, Gordon Sim <[email protected]> wrote: > 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. > > 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: > [email protected].**org<[email protected]> > For additional commands, e-mail: [email protected] > >
