Containment in the Core? (was "Re: [provision] Relationship models")

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

Darran Rolls wrote:

> 4 - To allow the following relationship types to be expressed:
>     4.1  Containment at the point of PSO creation and as an optional 
> interface.  A sample containment relationship would be between and 
> organization and its members

CONTAINMENT AT CREATION
We thought that we could express containment at the point of PSO 
creation by adding a 'parent' parameter to the 'create' operation; the 
target is the default parent.  Another approach would be to define a 
'createChild' operation within an optional interface.  The provider 
would then advertise in the target capabilities the set of object types 
for which this operation is supported.

ADDITIONAL CONTAINMENT OPERATIONS
What else (that is, what other operations) would we need to support 
containment?  I think we'd want to be able to:
- setParent (rebind an object beneath a specified parent)
- getParent (return the object beneath which the specified object is bound)
- listChildren beneath a parent (oneLevel or allLevels)
- ? getChildren beneath a parent (oneLevel or allLevels)
- query based on containment (e.g., "hasParent" or "hasChild") relationships

Note that if we support query based on containment, then we don't really 
need 'getParent', 'listChildren', or 'getChildren'.  (However, we'd 
still need 'setParent'.)

SUGGESTIONS
It's probably too early to know whether we want to reflect containment 
in the core.  However, we may be able to "cluster" the options and 
propose two alternatives.

IF CONTAINMENT IS IN THE CORE
If the core operations support containment, then I'd suggest we not add 
a bunch of new operations:
- 'create' takes an optional 'parent' arg (default parent is the target)
- 'search' recognizes two special attributes: 'hasParent' and 'hasChild' 
whose values are PSO IDs.
  NOTE: At this time, 'search' is not in the core.  It is defined in an 
optional interface.

IF CONTAINMENT IS AN OPTIONAL INTERFACE
If containment is an optional interface, then I'd suggest that we make 
containment-related operations explicit:
- 'createChild'    // creates an object beneath a specified parent.
- 'setParent'       // moves/rebinds an object beneath a specified parent.
- 'getParent'       // returns the parent of a specified object.
- 'listChildren' (oneLevel or allLevels)  // returns the ids of objects 
bound beneath a specified parent.
? 'getChildren' (one Level or allLevels)      // convenience method; not 
sure we want this.

We must either add an explicit 'createChild' operation or enhance the 
core 'create' operation to add an optional 'parent' argument. 
(Otherwise, if  'create' binds objects directly beneath the target, a 
requestor would have to first create an OU under the target and then 
move the OU to its parent.  This will probably cause name collisions, 
which the requestor would have to work around by creating, moving and 
then renaming.   Kinda  clunky.)

It seems slightly asymmetric to enhance the core 'create' verb to 
specify containment and not to support querying for children or 
parents.  (I could live with it, but it feels weird.) If containment is 
not part of the core, then it seems most consistent to have the optional 
interface define a 'createChild' operation.

JUST TO TAKE A POSITION
Unencumbered by knowledge, I'd say that I'd prefer to have containment 
be an optional interface.  We want to keep the core operations as simple 
and generic as possible, and containment would require some complication 
(and may impose some semantics--e.g., with respect to naming).

We also said that we wanted the core operations to apply to everything, 
and not every type of object will have a parent.  Defining containment 
as an optional interface allows a provider to specify (via target 
capabilities) for which object types it supports containment.

Gary