OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

amqp message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [amqp] Management wd08: scope of "name"


Great catch!

More generally, why unique within the management node in particular?
We already implying some kind of name scoping.

Perhaps we could copy what SQL does (most DB's have variations on this).
or just
select from TABLE
(I'm talking about the general hierarchy concept, not the syntax)

Ideally, as an end user, I would like:
1) To script operations on a managed object, and be able to move that object to another container without changing my code or management scripts.
2) Write code without being aware of the type of object I'm working on too much.  Moving from topics to queues shouldn't change everything (just some things).  Just like tables and views, to draw the parallel again.
3) Admit legacy systems where everything must have a unique name (e.g. queues and topics).
4) Admit systems were queues and topics might have the same name, but be in separate spaces.

All these suggest a containment hierarchy of some kind to disambiguate names and imply the notion of a current or default namespace for certain operations (I realize this is bad in its own way).

I really don't want to see "type" affect naming, rather containment.  So a system might implement a name container to hold all topics and a separate one for all queues; but this would not be mandated.

Finally, the type names in amqp are getting really long.  Do we have to do the Java thing?!  After all, to play these things are already talking amqp - so can we not just reserve a shorter prefix?


PS. I really would like to not see type-based inheritance enter the design of AMQP at this early stage or we start drawing in whole new classes of problem (pun intended!)

On 12 May 2014 16:30, Ted Ross <tross@redhat.com> wrote:
In section 2.4.1 "Attributes", it is stated for both "name" and
"identity" that:

"It MUST be unique within the Management Node through which it is accessed".

This kind of makes sense for identity since this field will likely be
generated by the management node on behalf of the entity.

For name, however, this is more problematic.  The name will be used to
descriptively identify an entity and if it is going to be unique for the
management node, it will need to contain the entity type (i.e.

Might we relax the requirement for name such that it must be unique
within the entity-type that is used to view the entity rather than the
whole management-node/container?


To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]