Re: [provision] SPML 2.0 Relationships proposal...

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

Jeff Bohren wrote:

> [JSB] I'm not going to word smith this document much. It's just a
>
>proposal. The real word smithing will be done to the actual spec, after
>we decide on the technical details.
>  
>
"Wordsmithing", huh?  If you had to explain this when we were reviewing 
the document, it probably deserves a sentence, don't you think?  Same 
reply to all "wordsmithing" issues: 3, 6, etc.

>5) Along the same lines as the previous comment, I'd suggest that we 
>rename the 'move' operation to 'setParent' or 'setContainer'.  (I know 
>that 'move' means 're-parent' in LDAP-land, but I'd prefer to make this 
>more explicit.)  Of course, "spmlcontain:SetParentRequestType" could 
>still extend "spml:BatchableRequestType".
>
>[JSB] I'm not concerned too much about what we call this, however
>"re-parent" would be inappropriate as it could be called on a PSO that
>does not already have an explicitly defined parent.
>  
>
I did not suggest calling it "re-parent".  I suggested calling it 
'setParent', which would make sense whether or not the target PSO 
already has a parent.

>9)  I think you forgot a field: "Connection Type".   You could call this
>
>"Relationship Type", but it's the same idea.  Several connections, each 
>of a different type, may connect any two objects.  Each connection type 
>in essence defines a separate namespace.  (Without this, a request to 
>delete or modify a connection might remove or update the wrong
>connection.)
>
>[JSB] The Reference ID is the "Connection Type". For instance if a user
>is a member of two groups and owns a PDA, there references might be:
>
>1: refID=memberOf, referentID=group1
>2: refID=memberOf, referentID=group2
>3: refID=owns, refentID=PDA12
>
>  
>
Perhaps this needs a little "wordsmithing".  I certainly didn't 
understand this from your write-up.

>10)  I really wish there were some way to avoid making the (optional) 
>relationship object a PSO (and giving it an ID).  As we discussed at 
>Long Island, persistently storing these objects (and mapping each to the
>
>appropriate target object or API) creates scale problems for a 
>provider.  Experience suggests that the number of connections may be an 
>order of magnitude or more greater than the number of objects connected.
>
>Rather than identifying a complex connection by an ID, could we specify 
>a complex connection instance by its From ID, To ID, and Connection 
>Type?  If a provider can map these identifiers to the appropriate target
>
>object or API, then we avoid persistently storing each complex 
>connection object as a PSO (and continually having to map its ID).
>
>In the case of the RACF, these arguments map cleanly to the API.  In the
>
>case of a directory object, it might be necessary to find the connection
>
>object by starting at one end (either source or target) or by searching 
>for an object that connects both the "fromID" and the "toID".
>
>As a consequence, one would modify connection attributes by passing any 
>object representing a complex connection as part of the 'connect' 
>request.  A single 'connect' verb could implicitly modify any existing 
>connection between the specified "from" and "to" objects (as it does in 
>RACF), or we could define separate  verbs to "addConnection" and 
>"modifyConnection".
>
>Do you see any problems with this kind of approach?  Is it possible to 
>avoid representing each complex connection object as a PSO?
>
>[JSB] It is possible if the following restrictions are made:
>1) There can not be two references with the same "from" and "two" IDs
>but with different attributes.
>  
>
I think your first restriction should be reworded to:
1) There can not be two references _of_the_same_type_ with the same 
"from" and "to" IDs.
or
1) There can be at most one reference of a given type between two 
objects A and B.

>2) The attributes are always updated as a set. In other words one RA can
>not try to set the "admin" attribute on the same relationship while
>another is trying to set the "audited" attribute on the same
>relationships.
>  
>
I do not understand why the attributes would have to be updated as a 
set.  In RACF-land, it is entirely appropriate for one caller to modify 
the "SPECIAL" flag on a connection while another caller modifies the 
"OPERATOR" flag on the same connection.  In LDAP-land, can't one caller 
modify an attribute of a name while another caller modifies another 
attribute of the same name?

Can't a modification request specify the element or attribute it intends 
to add, replace, or delete?

I think I may know the source of our "disconnect".  You proposed adding 
state to connections by adding a level of indirection.  What you called 
the "Reference Attributes ID" is a reference to another object that 
represents any "extra information" stored on the connection.  In your 
proposal, that object is stored persistently as a PSO and is specified 
by a PSO ID.

I like the idea of having an object that represents the "extra 
information" stored on the connection, but  I'm trying to avoid storing 
(and modifying) that object as a PSO (for the reasons of performance and 
scale we discussed at Long Island).

1) If a connection object were passed as an optional argument to the 
'connect' request, then the connection object could be arbitrarily 
complex. 
2) A connection object passed into a 'connect' request could also be 
used to update an existing connection: any specified element or 
attribute would overwrite the corresponding element or attribute of the 
existing connection (as it does in RACF).  On the other hand, it might 
be cleaner to have a separate operation to modify connections.  A 
'modifyConnection' request could either replace the entire connection 
object or could add, replace, or delete specific elements or attributes 
of the connection object.   I don't care much how we do this, as long as 
there is a way to do it.

The big point is that a connection object (and modifications to a 
connection object) can be mapped to an appropriate target object or API  
*without* having to store and identify the connection object 
persistently.  Knowing the connection type, from id and to id is 
enough.  This keeps the ID namespace and PSO storage requirements an 
order of magnitude (or more) smaller.

>I think trying to avoid making the attributes a PSO is going to cause
>more effort on the implementers than it is going to save.
>  
>
You may be right, but I don't see it yet.  I'm kinda slow that way.  
What additional efforts do you foresee?

>11) Same as (9): need "Connection Type" in order to uniquely specify an 
>connection (instance). 
>[JSB] I don't understand this one.
>  
>
You explained above that you intended ReferenceID to be what I call 
"Connection Type".  (I should have explained that the same comment that 
I made for the Add Request should also apply to the Modify Request.)

Gary