(v13) Files, devices, device types, channels, and channel classes

This page applies to Harlequin v13.1r0 and later; both Harlequin Core and Harlequin MultiRIP.

The distinction between files, (i/o) devices and device types is not always apparent, and in many cases, it is not necessary to make the difference clear. We may talk about the “config file” and the “config device” more-or-less interchangeably, and use “AppleTalk device” when, strictly speaking, we mean “AppleTalk device type” or even “AppleTalk channel class” (see below). However, the concepts are distinct. This section discusses these distinctions.

The core RIP, a component of all RIP implementations, provides support for devices and device types. In the GUI, three particular device types provide a further layer of abstraction, implementing an interface to plugins through channels and channel classes. This provides the means for device types and filters (see (v13) Filters ) to be coded in plugins.

A channel in the Harlequin RIP is the structure used to represent a device to an input plugin (usually instantiated by the end-user in the Input Manager). Each channel belongs to a channel class—channels belonging to the same channel class share most characteristics so that they can be implemented by a common piece of code in the plugin (and it is channel classes that are being identified by the Type field in the Input Manager Edit dialog). Therefore, channels are to channel classes as devices are to device types.

A channel class is created by a plugin; a channel is created by the skin in response to a device being mounted on one of the plugin device types and forms an interface between skin and plugin; a device is created by the core RIP in response to a mount on any device type and forms an interface between core RIP and skin; a device type is created by the skin when the Harlequin RIP is started; and a file is created in the core RIP by the interpreter in response to a file or run operator.

A file is usually regarded as a permanent collection of data. However, in most programming environments, a file is more accurately a data structure which provides access to a collection of data; the data is not necessarily permanently stored: file structures are used to access serial lines and the like, as well as disks. In PostScript, a file is the object which results from using the file operator.

The Harlequin RIP limits all user created names or file names to 31 bytes. This is equivalent to 31 characters when using standard ASCII text, and 15 characters when using double-byte character sets, such as Kanji.

A file exists and is opened “on” a device. Except for non-relative devices (see (v13) File names, device names, and relative devices), in principle there can be an unlimited number of files on any device. If a file is the communications medium for data, a device can be regarded as the source or destination for the data: a specific disk, a particular printer, a bank of memory, and so on. A device is referred to in PostScript by a string object in which the first (and optionally the last) character is a percent sign; for example (%disk0%). It is introduced to the interpreter by the devmount operator. The setdevparams operator sets properties of a device that can be varied.

A device type defines the behavior and purpose of devices associated with that device type. A device type is identified by a unique number. A device is associated with a device type when the DeviceType parameter is first set for a device (using the setdevparams PostScript-language operator); until then a device can exist but is in a disembodied state where the only permitted operation using the device is setdevparams —see (v13) Device parameters and setdevparams.

Once determined, the type of a device cannot be changed. Any attempt to change it is ignored.

In general, a many-to-one relationship between files and devices exists (and also between devices and device types). In the GUI version, a one-to-one mapping of channels onto devices is associated with the plugin device type. Also, a many-to-one relationship between channels and channel classes exists (and therefore between plugin-devices and channel classes). These relationships are illustrated below: