[DGD]DGD extension interface, some thoughts

[Felix A. Croes]

At initialization time, a specific function will be called to
initialize external modules.  By default, this function will exist
in dgd/src/config.c and do nothing.  Module writers should supply
their own version of this function.  The preferred method will be
to comment it out in config.c, and link DGD with additional module
code at compile time.  Replacing the function will be the only
change that has to be made to the source code of DGD itself.

At module initialization time, the following actions are possible:

 - add a kfun
   Add a kfun using a regularized interface, possibly replacing a
   builtin kfun.  At runtime, the kfun will be called using a
   simplified interface; conversion to and from this interface is
   the responsibility of DGD.
   Normal kfuns are stateless.  However, a kfun may be defined that
   marks an existing object as "special", as explained below.
 - change swap mechanism
   Replace the existing low-level swap routines in some way still
   to be determined.  The goal would be the ability to let DGD
   preserve its state in a standard database, rather than a swapfile
   and state dump files, for extra reliability and perhaps interesting
   rollback features.

Special objects in DGD have some additional meaning that is external to
the ordinary LPC environment.  Examples of such objects are user
objects, editor objects and parse_string objects.

A kfun may mark an object as special.  Thereafter, the object becomes
associated with some external state or context.  DGD recognizes only
one type of special object; differentiating between several types is
the responsibility of the module writer.  A special object cannot be
also a user, editor or parse_string object at the same time.

The management of an object's external state is entirely the
responsibility of the module writer.  However, special objects
have some additional features:

Each special object has an extra hidden variable which is not
accessible from LPC code.  A kfun can store typical LPC data in this
variable, so that the "external" state of an object does not need to
be separately allocated but can be swapped out with the object, or
even stored with the object in a state dump.  Furthermore, changes to
this value will automatically be undone by atomic code when required,
so that the special object can conform to the atomic state.

Whenever an LPC-level function is called which is defined in the
program of a special object, the call may be redirected to a C-level
function, which will be called using the normal kfun interface.  It
will not be possible to call LPC functions from there.

At the end of each thread, a module-supplied function will be called
for cleanup purposes.  Another module-supplied function will be
called when a special object is about to be swapped out.

				-*-*-*-

Comments are appreciated.

Regards,
Dworkin

List config page:  http://list.imaginary.com/mailman/listinfo/dgd