Oberon || Library || Module Index || Search Engine || Definition || Module

Ulm's Oberon Library:


TranslucentNames - translucent layering of name hierarchies


CONST mergesort = 0;
CONST unsorted = 1;
TYPE DirMode = SHORTINT; (* mergesort or unsorted *)

PROCEDURE Create(VAR node: Names.Node; readonly, writable: Names.Node; rauth, wauth: Shards.Lid; status: Names.Status; dirmode: DirMode);

PROCEDURE CreateFactory(VAR factory: NodeFactories.Factory; readonly, writable: ARRAY OF CHAR; rauth, wauth: Shards.Lid; status: Names.Status; dirmode: DirMode);


TranslucentNames allows to combine two name hierarchies into a new hierarchy where

In other words: We are operating on the second hierarchy but the first hierarchy is seen through the second hierarchy as long it is not covered by existing entries of the second hierarchy.

Whenever a node of the translucent system is asked for a list of members (Names.GetMembers) a list of names is returned which consists of entries of the second hierarchy and, as long as their names are not present in the second hierarchy, of entries of the first hierarchy. The order in which these names are presented depends on the selected dirmode:

Assume that both hierarchies return alphabetically sorted member lists. Then this directory mode causes the translucent hierarchy to return sorted member lists as well. Note, however, that if this assumption does not hold, the same name can be returned twice in a member listing.
Do not assume the hierarchies to be sorted and do not generate a sorted member list either. Instead, the members of the second hierarchy are returned in their original order, followed by the members of the first hierarchy whose names are not present in the second hierarchy, again in their original order.

TranslucentNames supports the proxy framework of Proxies and uses the directory nodes of the second hierarchy as heirs for the creation of translucent directory nodes. This means that if a directory node of the second hierarchy is of an extended type of Names.Node that is supported by Proxies, the corresponding node of the translucent hierarchy will be of this extended type as well.

Create returns a newly created translucent hierarchy in node that combines readonly (as first hierarchy) with writable (as second hierarchy). On all operations delegated to readonly, rauth will be passed on as authorization. Likewise wauth will be passed to all operations forwarded to writable. The access to directory nodes of the translucent system itself must be authorized according to the status parameter. The directory mode dirmode determines how member listings are composed out of the listings from the two underlying hierarchies (see above).

CreateFactory takes the parameters as Create and returns a newly created factory that generates translucent hierarchies as specified by these parameters.


TranslucentNames generates some error events using Names.Error with following error codes: Names.nodeNotFound, Names.nodeDestroyed, and Names.noPermission. More events can be generated by the underlying implementations.


general abstraction for name hierarchies
framework for proxy objects

Edited by: borchert, last change: 2004/09/20, revision: 1.1, converted to HTML: 2004/09/20

Oberon || Library || Module Index || Search Engine || Definition || Module