/**********************************************************************
*
*    TODO
*    ====
*
*    This TODO-file includes information about
*    future plans of development for the DB module.
*
*    (C)rebro University 2007-01-01    http://www.tech.oru.se/cad
*
***********************************************************************/

The DB module was originally developed in 1984 exclusively
for the Varkon system. A lot of job has been put into the
code since then, but still only with Varkon in mind. With
the release of the DB sources under GPL in 1998, the situation
has changed and Varkon is no longer the only user of the
DB. Many of the TODO:s are things that Varkon doesn't need
but may be needed by other applications.

Some of the TODO:s would be easy to fix if DB file backward
compatibility was not an issue. A lot of files have been
created with this DB since 1984 !

1. Adding entities to a part. When calling DB_insert_part() to
   start the creation of a new part you must know in advance
   how many entities the part is going to consist of. This is
   due to the fact that DBinsert_part() needs to preallocate
   memory for a fixed size ID table. After having called
   DB_close_part() it is currently not possible to add any
   new entities to that part. You can delete or update but
   not add new since this would implicate a new ID and the
   size of the ID table is fixed. What I need to do is to
   write an ID table reallocation routine that can extend the
   size of an ID table. Not very difficult. Then I could add
   a DB_add_entity_to_part() API function.

2. Garbage collection. This you can work with forever. Current
   method is not 100% waterproof and not the fastest possible.

3. Error messages. DB calls erpush() with a unique error code
   when an error is encountered. Each errorcode also has a
   corresponding message text in an external file (GM.ERM).
   To make it possible for an application to record error
   messages and display message texts the application has
   to provide it's own version of erpush(). A nice way to
   do this would be to make it possible for an application
   to register it's own error callback that would be called
   by the DB.

4. Handling of multiple instances. The DB supports multiple
   instances of an entity with the same ID sequencenumber
   through the ordernumber mechanism. This is very powerful
   but the implementation is rather slow. Instances are stored
   in a singly linked list. A list with forward AND backward
   pointers would be much faster in some applications.

5. Multiple RES-files opena at the same time. This would make
   it possible to read/write data between different models.
   Could be implemented using a "DBContext". In MBS you could
   set an "active" DB.
