[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Fwd: [Fwd: [management] Name and Identity - too much?]
From Alan Conway... -------- Forwarded Message -------- Subject: [Fwd: [management] Name and Identity - too much?] Date: Tue, 25 Nov 2014 09:39:55 -0500 From: Alan Conway <aconway@redhat.com> To: Ted Ross <tross@redhat.com>
--- Begin Message ---
- From: Alan Conway <aconway@redhat.com>
- To: amqp@lists.oasis-open.org
- Date: Mon, 24 Nov 2014 11:28:12 -0500
[Tried to send this last week but not properly subscribed...] I have an issue with: name and identity in the current spec: The user MUST supply unique name, system MUST supply unique identity. This raises some problems: - It is redundant to require 2 unique identifiers for each management entity. - It imposes unreasonable complexity on the user to require unique names for every entity type. Providing unique names is not trivial for the user, since more than one user may independently create entities. It needs some form of central ID management, UUIDs, application namespaces or other technique. Many entity types have no need for an additional key attribute beyond the system-generated "identity" so the effort of generating one is wasted. Conversely some applications might may need more than one application-defined searchable key for some entity types. Proposal: 1. Drop the special "name" attribute, keep "identity" as presently specified. 2. Add attribute-based query, allow the user to query based on whatever attributes they wish. Attribute-based query could be an extension to the QUERY operation or a new operation. The simplest possible query is simply an attribute name X and a string value V, meaning find any entity who's attribute X == V. That would be sufficient to replace the current "name" attribute, but already more flexible (User can locate objects by "partNo", "upcCode" or whatever they wants, and can query by more than one attributes.) Obviously we could extend this to more complex query expressions allowing multi-attribute queries etc. If we can settle on one that suits everybody that would be ideal. Another possibility is to introduce a "query-type" attribute on the query operation, where all MUST implement the simple name/value query, but MAY use query-type to indicate an extension query languages or future specifications MAY define more sophisticated queries. Cheers, Alan.
--- End Message ---
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]