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

 


Help: OASIS Mailing Lists Help | MarkMail Help

provision message

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


Subject: Containment in the core might not be so bad.


I'm thinking that having the core operations support containment might 
not be so bad.  Let's examine the original objections in  the context of 
a specific example. 

A Unix system is the classic example of a target that does not support 
containment.  There is a flat namespace for users and a flat namespace 
for groups. (A NIS Domain looks like a more generic version of the same 
thing.)  There are other examples of targets with flat namespaces, but 
Unix is familiar.

The first objection is that it would be burdensome for a provider to 
implement the containment operations for a target that does not support 
containment.  Assume that containment operations include 'add(child, 
parent)', 'setParent', 'getParent', and 'listChildren".

The second objection is that requestors would have to 
"program-by-exception"
in order to handle containment operations not implemented by a provider 
for a target.

The first thing that occurs to me is that the schema for a Unix target 
would not expose too many classes that even look like containers.  There 
might be just two object types: User and Group.  (A richer provider 
might expose classes to represent filesystems, hostnames, or aliases, 
but even these don't look much like containers.)

The next thing that occurs to me is that, while some of the operations 
might be crippled or might fail, what appears to be "crippling" is 
simply the mapping of a richer interface onto a simpler 
implementation.   The ways in which containment operations might fail on 
a Unix system are not qualitatively different from the ways that the 
same operations might fail on an LDAP directory service if the arguments 
were inappropriate.
- 'add(child, parent)' would fail when any parent
   (other than perhaps the target itself) is specified.
- 'setParent' would fail whenever it was called
   (or perhaps would fail whenever
   the specified parent was not the target itself).
- 'getParent' would always return null
   (or perhaps always return the target itself).
- 'listChildren' would always return null
   (unless perhaps it was called on the target itself,
   in which case it would list all the objects
   bound beneath the target).

These failures are no different from the way that the same operations 
would fail,
even for a provider target that does support containment,  when the type 
of the specified
parent object is incompatible with the type of child object.

Gary P Cole wrote:

> Mr. Bohren several times mentioned that he wished the core operations
> supported containment.  Participants recalled the main
> objections raised when this approach was originally discussed:
> - The burden (and oddity) of a provider implementing
>  required containment operations
>  when the underlying target does not do so.
> - If a provider does not implement containment,
>  the requestor must "program-by-exception".
>
> Nonetheless, participants felt that it was worth
> re-examining this "Core" approach in case it turns out
> to be less heinous overall.




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