[DGD]DGD extension interface, some thoughts

[Ludger Merkens]

On Tue, 26 Sep 2000, Felix A. Croes wrote:

> 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.
>

Is there a way to remove this restriction? Assume you wan't to write an
XML parsing toolkit, e.g. with sax interface, you'd really like to use
callbacks to lpc to handle the tags. Another problem I see would occur if
somebody wanted to change the netpackage into a module, since this also
calls lpc callback functions. Especially interesting would be to let the
module run in its own thread and call the cb-functions from there on
demand.
 
> 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.
> 
interesting ideas, i'm looking forward to it.
> Regards,

Ludger


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