PSO IDs: GUIDs or names?

[Gary P Cole <Gary.P.Cole@Sun.COM>]

In the most recent working group call, I promised to start an email 
thread to discuss PSO IDs.  We should reach a conclusion on the 
semantics of IDs *before* the next face-to-face--or at least have a 
clear and common understanding of the issues.  The following ought to 
get things started. :-)

I believe that a PSO ID should be globally unique and immutable. Any 
identifier that is not unique or can be changed is some kind of  "name". 

Only a unique identifier will work well in a hash or cache.  Only an 
immutable identifier will work well in a cache.  (Otherwise, you need 
some way to detect renames and then you need a way to update any cached 
or persistent references.  The only reliable schemes I know for 
detecting renames and updating references rely on having another unique, 
immutable identifier.)

I believe that an ID must be *globally* unique because a single 
requestor could hold IDs from several different providers.  If these ID 
values could overlap, then the requestor would have to prefix each ID 
with an identifier for the provider in order to make the value unique.

I think that the provider must assign the ID value to any PSO that is 
added.  (If pressed, I will agree that it's okay for a requestor to 
*suggest* an ID, but I don't see how an ID can be guaranteed to be 
unique in the namespace of the provider unless the provider has the 
final say.)

This came up again because Jeff Bohren said that moving an object to a 
new container could change its ID.  I said no, that moving an object to 
a new container might change its *name* (or its pathname, or its DN), 
but not its ID.  Otherwise, simply setting a new parent on an object 
could invalidate (cached or persistent) references to that object.  Even 
if requestors and providers have some way to "listen" for renames, there 
is no guarantee that all those maintaining references to the renamed 
object will be available at that time.  The only way I know for 
references to reliably survive renames is to have some kind of a GUID 
instead of (or in addition to) the name.

If we want to have "friendly", mutable and non-unique identifiers, then 
let any PSO have a Name (in addition to its ID).  A name is better for 
most display purposes.  But provider API operations should assume that 
any ID is a globally unique and immutable value they can trust.  
Requestors should know that any cached or persistent reference must 
include the ID.

Gary

Gary P Cole wrote:

> 3)  Gary Cole will start an email thread to discuss
>    issues related to the semantics of PSO ID:
>    - scope of uniqueness
>    - mutability
>    In short, are IDs GUIDs or are IDs names?