5. Re-engineering PLINTH to accommodate OODBs

The main work that has to be done to allow PLINTH to use an OODB is the reimplementation of the CONNEKT subsystem to make it create and manipulate external database objects instead of the records shown in figure 1. In order for this to be done with minimum disruption to the rest of the system code, the programmatic interface to CONNEKT should stay essentially the same.

However, at the moment CONNEKT data is not sufficiently well hidden - other PLINTH modules can directly access the fields in the net, node and link record structures in order to get information about the objects. The first stage of the process is therefore to encapsulate the CONNEKT subsystem fully, to formally define and fix its own API (this has only been done informally up to now), and to ensure that rest of the PLINTH system code adheres strictly to the defined interface. Once this has been done, we will be free to re-implement either CONNEKT or the GUI independently of each other, whenever it becomes necessary to port PLINTH to a new OODB or a new window system. Given that the CONNEKT code is already quite modular in most repects, this will not be a major task.

This definitive CONNEKT API should of course take into account the special requirements of a possible OODB implementation, even though this will not necessarily be transparent to the application program (i.e. the rest of PLINTH). For example, consider the n_linksfrom and n_linksto fields of the node record in figure 1. The contents of these fields are Pop11 lists of link instances. However, in an external OODB with a C interface, we might well have definitions similar to the following:

When the Pop11 application program needs to know the links from or to a particular node, we do not want to have to create a new Pop11 list every time to shadow the external linklist structure, as this will cause garbage problems. Neither do we want to simply pass the Pop11 program an external pointer to the C structure and expect it to know how to traverse it, as this will break the data encapsulation. The solution is not to have the API provide an access procedure that returns a list of links (as it does currently), but rather a procedure that returns the next link each time it is called, until there are no more (i.e. in Pop11 terms we need a `link repeater').

It is also likely that some existing CONNEKT procedures and structure fields will become redundant when an OODB implementation is used, for example the loadnet and savenet procedures (though the latter might be changed to call a `commit' function in an OODB with atomic operation sequences as described in 2.2 above).

Conclusions...