[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]