Introduction
Although MFS are used for a great variety of purposes, the basic structure and logic is much the same for any MFS. This section provides general information about the construction and programming of an MFS.
MFS Basics
An MFS is a subroutine like any other in OpenInsight. Because of this, developers are free to create an MFS in any manner they choose, as long as the calling protocols for the subroutine are observed. An MFS can be written in BASIC+, in C, C++, or in assembly language. Developers can choose the language best suited to the application of the MFS, and to their coding preference. For example, an MFS that compresses data might best be coded in a low-level language for speed purposes.
Filing System Access
OpenInsight file operation requests originate in BASIC+ commands such as READ, WRITE, DELETE, LOCK, UNLOCK, SELECT, READNEXT, or in System Monitor routines such as ATTACH_TABLE, DELETE_ROW and LIST_TABLES. Developers write these commands into their programs, or execute the routines from the System Monitor, to control the flow of data to and from the file.
When a program or routine executes, each file-oriented statement becomes a call to the filing system. For example, if an BASIC+ program encounters a READ statement, and the file being read is a Linear Hash file, OpenInsight generates a call to the program RTP57, the Linear Hash BFS, with the appropriate "read" code.
Because BASIC+ is independent of filing systems, the call arguments for filing system subroutines use a standard protocol. BASIC+ produces the same subroutine call for all filing systems, always using the same arguments. A
READ statement, for example, always produces the same BFS call, regardless of what filing system is actually being accessed by the read logic. By extension, all MFSs must use the same calling conventions.
MFS "Trapping" Mechanism
If an MFS has been installed onto the file being accessed, the MFS "traps" or "interrupts" the call to the underlying filing system. Instead of calling the BFS, OpenInsight calls the MFS first, passing it the same arguments that would otherwise have been passed to the BFS.
Because the full list of arguments is available to the MFS, including the name of the operation to be performed, the MFS can examine and manipulate any of the arguments.
BFS/MFS Independence
When creating an MFS, a programmer must consider carefully the environment and purpose of the MFS. Developers should remember that an MFS can (and should) function generically within the OpenInsight system.
In an ideal system, an MFS is compatible with all possible BFSs. At the same time, an MFS should be prepared to handle the full range of calls that might pass to it from higher levels of the system.
To maintain true independence of an MFS, it is important that MFS programmers not assume information that is unique to a BFS. For example, each BFS uses a unique structure for its file handles, lock semaphores, and select pointers. An MFS that is designed to manipulate any of these based on a specific structure will become BFS-bound, and will not be installable on files associated with different BFSs.
As another example, it would be very inflexible to build direct calls to RTP57 (the Linear Hash BFS) into an MFS. Doing so would preclude installing additional an MFS for the file, and would prevent the MFS from being used for other filing systems.
Of course, there is no restriction on the creation of such a BFS-bound MFS. Particular applications will occasionally require precisely this type of MFS for reasons of efficiency or security, or for other reasons. Under these circumstances, an MFS programmer is wise to build checks into the MFS (such as testing the BFS argument) to insure that if the MFS is inadvertently linked to the wrong BFS, it is able to recover and proceed.
