Those of you with long memories may well remember the heyday of Advanced Revelation when it seemed that every week somebody would come out with a new BFS – or “Bond” as we then called it. Starting with Icicle Software and their Lotus 123 bond followed by AS400 bonds, dBase bonds, SQL Server Bonds, Universe Bonds – the list grew and grew. These days though we seem not to hear quite so much about them so we thought that with the forthcoming re-introduction of the SQL Bond in 9.2 it might be time to revisit this subject.

So what is a BFS?

The clue is – as ever – in the title. Base Filing System. A Base Filing System is the lowest level of file system available in a Revelation environment. Ultimately it is an abstraction of all of the operations required to manipulate a particular file format encapsulated into one conceptual black box program. We say “conceptual” because there is nothing stopping a BFS being made up of more than one program – a classic example of this is the Linear Hash BFS, which uses both RTP57 and RTP57A to implement Linear Hash.

Consider the problem faced by Revelation back in the day. They wanted to create a tool set that could work against ANY back end without requiring reprogramming. Such a tool set would be a boon for developers and users alike. So they came up with the concept of a BFS. They created a list of primitive codes that a filing system would need to support and the codified this in the BFS standard.  Basically they said “if you respond in the following manner to the following requests we really don’t care what it is you’re talking to on the back end”.

So how does it work?

In the first instance we need to provide OpenInsight with some information about the data we're trying to access. If you think about it, all that OI needs to be told is just the name of a data row that defines both the location we're interested in and the name of the BFS to use. And this is exactly what a volume pointer is. Now admittedly it might need some additional information such as where to keep shadow dictionaries but location and the BFS are the main constituents.

Attaching a volume could be mapped as follows :-


So let's describe a simple application of this by reference to an imaginary BFS called dBASE.BFS which is a program that has been created to read and write dBASE files. We can obviously store dBASE files anywhere on the disk so we need to tell OI their exact location. Let's assume that we're going to keep them in DATAVOL - yes we can mix and match different file types at the same location because we're using different BFSs. So to "dry run" the above diagram we firstly create a volume pointer called "DBASE_INFO" that tells OI that the BFS is called DBASE.BFS and that the location is called DATAVOL...

• Attach a volume - we ask OI to attach DBASE_INFO

• Read Volume Pointer - OI reads the volume pointer and gets back DBASE.BFS : @Fm : DATAVOL

• Determine BFS - OI takes field one

• Determine location - OI takes field two

• Call BFS passing location - a series of calls are placed to DBASE.BFS asking it to open the media map for the location, select the rows in the map and return these rows. In actuality the DBASE.BFS would implement this by doing an InitDir(Location : "\*.DBF") and returning the file list

• Update SysTables - SYSTABLES would have the names of the DBF files added into the array along with the fact that they use the DBASE BFS

So now if you looked at SYSTABLES you would find rows for each DBF table detaiing its location and the fact that it uses the DBASE.BFS. For the sake of argument let us assume that one such row was called MEMBERS.DBF.

Now when we come to want to open the file for any reason RTP9 (the routine responsible for opening files) would be called with the parameter MEMBERS.DBF. It would read the row from SYSTABLES and establish that the BFS used for that file was DBASE.BFS. It would then call DBASE.BFS passing it the location and the name of the file to open - so DATAVOL and MEMBERS.DBF. DBASE.BFS would simply validate that the file existed and if it did it would return a file handle which could have any structure that the DBASE.BFS wanted as long as it followed the syntax BFS_NAME : @Vm : HandleIdentifyingFile. In its most simple form this could be DBASE.BFS : @Vm : MEMBERS.DBF. This resulting handle would be put into the variable that the file was opened to and would become our file handle.

So now we have a file handle. When we come to read or write to the file handle OI is completely agnostic as to what the BFS actually is. It doesn't care if we are reading or writing Linear Hash, DBASE or SQL. The engine in its role as opcode interpreter simply comes across the opcode for, say a read and says "Oooh a read - so the next opcode will identify the file handle, the next opcode will identify the row id and the next opcode will identify the variable to place the resultant read in". It then looks at the file handle and effectively says

FirstBitOfFileHandle = FileHandle<0, 1>
Call @FirstBitOfFileHandle(Read, FileHandle, RowId, Record, Unused, Flag)

which you'll recognise if you've ever written an MFS. It is then down to DBASE.BFS to implement the read as it sees fit - as long as it sets the Flag variable to indicate a successful or unsuccessful operation (and in the event of it being unsuccessful ideally sets @File.Error to indicate the nature of the failure) OI will be perfectly happy.

So in conclusion - BFSs abstract the logical layer from the physical layer and OI tools work with the logical layer rather than the physical layer. If the BFS is well written then all of OI's data manipulation tools (Window, Popups, Rlist, Basic+ etc) will just assume that the underlying filing system is effectively linear hash.