RE: Channel concept instead of simple Files

[Guy Laden <laden@math.tau.ac.il>]

I think the discussion will benefit if were all familier with the Oberon/F
approach to the problem.  Incase anybody hasnt looked at Oberon/F
framework, I'm attaching the relevant parts of the documentation.

---

Device Drivers: Carriers, Riders, Mappers, and Directories

This chapter describes the strategy which is used for modeling device drivers, as well as data structures which can be accessed in a similar way as devices, e.g. texts.

Access to a device's data passes through two different objects: a rider and a carrier. A carrier represents a data container, e.g. a file or a screen pixelmap. Several access paths may be open on one carrier at the same time. This n:1 relationship gives rise to the separation of carriers and riders, where a rider represents one access path to its carrier.

The implementation of a rider must have intimate knowledge about the implementation of its carrier, e.g. a file rider must know about the disk sector corresponding to its current position. Thus an extension of a carrier usually requires an appropriate extension of its rider as well. As a consequence, a rider is generated by its carrier, which provides an allocation function for this purpose.




Picture a:  Carrier-Rider Separation showing N:1 Relationship


A rider provides primitive input/output operations, the so-called bottleneck interface. These primitives can be used to build more complex operations which form a higher-level abstraction, possibly even an application-specific abstraction. Such a higher-level abstraction will generally be called a mapper in this documentation. A mapper contains a rider as a link to the carrier. During their use, mappers and riders form 1:1 relations, i.e. pairs.




Picture b:  Carrier-Rider-Mapper Separation


In contrast to riders, mappers know nothing about a carrier's implementation, and thus can be extended independently. This independence means that every mapper may be used on any compatible rider, without the need to implement all combinations of mappers and riders individually. This situation is shown below for the case of riders that operate on serial carriers like RS232 links or networks:




Picture c:  Extensibility in two Dimensions


As was explained in chapter 1.7 ("From White-Box Frameworks towards Black-Box Frameworks"), Oberon/F generally doesn't allow the extension of concrete types. Mappers are exceptions to this rule, because by their very nature they create or interpret fixed external representations, e.g. number formats on screen or the representation of binary data on a file. Apart from possible optimizations for efficiency reasons, this fixed external representation practically defines the complete behavior of a mapper. A procedure whose complete behavior is known may safely be extended (i.e. empty procedures, default procedures, mapper procedures, procedures whose source code is published). However, mappers and message records are the only exported concrete types in Oberon/F.

Yet there must be a way to obtain objects of concrete types! For this purpose, a module which exports an interface type also provides a so-called directory object, accessible through a global variable. Such a directory provides functions to allocate new objects, and often also procedures for looking up objects by a given key (this property, although not always available, led to the generic term "directory"). For example, a file directory provides functions to create new empty files, as well as to look up existing files by name (a file directory object in Oberon/F does not, however, represent a single file subdirectory, but rather the whole file system).

Directory objects are powerful facilities, since they can be replaced at run-time (usually this is done during the boot configuration process). This makes it possible to add and integrate extended services at run-time (i.e. new concrete types), which allows a system to grow in a controlled manner.

To summarize:

- Carrier	container for data
- Rider	access path to carrier, bottleneck interface
- Mapper	creates or interprets external data formats using a rider as link to a carrier
- Directory	facility for generating or for looking up objects of concrete types


---

Guy