So, since I sent that mail I think we revised our thinking mostly based on arguments about what a "type" is (if everything is derived from org.amqp.Manageable" or something then the type restriction doesn't really help)... though I admit to hating it myself quite a lot. One option is to use a path like structure for names (as one might do in a REST API), so "/queue/foo" and "/user/foo" would be distinct... however this has the very undesirable effect of making it virtually impossible for a user to pick a name for the object they are creating unless they understand the scheme. Another alternative might be to say that different management nodes should be used for things that have distinct namespaces... so $management might know of two other management nodes $management.queues and $management.users and via meta data discovery you could work out where you would have to go to manage users, and where to go to manage queues... The next OASIS call is next week, it would be good if you could come along and we can have the discussion with the others involved.
-- Rob On 20 November 2014 22:10, Alan Conway <acon...@redhat.com> wrote: > On Wed, 2013-07-31 at 10:46 +0200, Rob Godfrey wrote: > > I've replied one technical point on the OASIS list: > > > > https://lists.oasis-open.org/archives/amqp/201307/msg00011.html > > In that message you say: " It is possible to have two objects of > differing types with the same name (e.g. a queue named “foo” and a > management node named “foo”)" > > I am pleased to hear that. I drew the opposite conclusion from 2.5.1: > > "A case-sensitive string identifying the entity. It MUST be unique > within the Management Node through which it is accessed. It MAY > change during its lifetime." > > "unique within the node" sounds like it has to be unique for _all_ > management entities in the node not just those of the same type. > > Can you clarify that for the next draft? The same goes for identity. It > makes a big difference - I put type prefixes on the names in my impl > which is ugly and redundant. I look forward to throwing them away. > > Cheers, > Alan. > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org > For additional commands, e-mail: dev-h...@qpid.apache.org > >
