ACEDB - in the Medium Term

Many of the commands available to acedb users via tace etc. have grown up in a slightly ad hoc. way. ACEDB release 5 will present an opportunity to revise the structure of the command interface. In particular there will be sets of command options for:

• maintenance

The interface to the acedb database is a bit adhoc and requires a programmer to know serveral different 'subsystems' of calls to open the database and read/write information to it. The idea behind acelib is to provide a more consistent database interface to make applications easier to write and provide more power to the applications (e.g. having more than one database open at a time).

The production of acelib will require:

Cleaning up the name space, including:

• deciding what is and what is not the kernel.
• choosing a prefix for use in the code (e.g. ace)
• renaming all #define symbols (whether defining values or macros) to start with the prefix from above
• renaming all external symbols (whether variables or functions) to start with the prefix from above
• ensuring all include files are guarded against multiple inclusion
• changing inclusions of acedb header files to be of the form #include so that the header file is qualified with an acedb include directory name and becomes part of the standard search list of include directories
• Restructuring header files into those that are for 'internal' use by kernel code only and those that are for external use by applications.

Removal of statics/globals and introduction of 'context'

currently much acedb code uses a crude 'object' model whereby a package holds instance data in static variables (both local and global). While in one sense this provides 'objects' it has a number of drawbacks:

• it is not reentrant so like strtok in the C stdlib, the packages must be used carefully
• it is not thread safe
• it means that only one database can be open at a time

A better approach is to get the application to create a 'database' context which it passes as a parameter to each call for operation on the database (see X Windows, X Toolkit etc). This way the database code does not need to hold any 'context' information for a particular database.

POSIX conforming

the library should use POSIX conforming system calls to make porting it to other platforms as easy as possible. This will become increasingly important as POSIX compliance becomes more complete.

A beta test version is available in ACeDB 4_8.

Need some information from Lincoln.