Introduction
Mosel works with a generalization of the notion `file'. In statements of the Mosel language (such as initializations from/to, fopen, and fclose) and in the Mosel library functions (e.g. XPRMcompmod, XPRMloadmod, or XPRMsetdefstream) the term `file' is not limited to `physical file handled by the operating system'. A `file' may be, for instance,
– a physical file (text or binary) |
– a block of memory |
– a file descriptor provided by the operating system |
– a function (callback) |
– a database |
The type of the file is indicated by an extended file name: the actual file name is preceded by the name of the driver that is to be used to access it. We now write, for example, mem:filename to indicate that we work with a file held in memory, or mmodbc.odbc:mydata.mdb to access an MS Access database via the ODBC driver provided by the module mmodbc. The default driver (no driver prefix) is the standard Mosel file handling. The general form of an extended file name is
driver_name:file_name or module_name.driver_name:file_name |
In the first case, the driver is defined by the Mosel core, the second form means that the driver is provided by the module module_name. The structure of the file_name part of the extended file name is specific to the driver, it may also consist of yet another extended file name (e.g. zlib.gzip:tmp:myfile.txt).
This paper describes the I/O drivers of the Mosel distribution with examples of their use. Some drivers provide interfaces to specific data sources (such as ODBC). Others serve to exchange information between the application running the Mosel libraries and a Mosel model in a very direct way by providing various possibilities of passing data back and forth in memory.
With the help of the Mosel Native Interface (NI) the user may also implement his own drivers. We introduce some applications of this feature: a driver for working with compressed files and an example generating C code with a Mosel model.