Re: scm_* API extension? [was] scm_* API question

[Marius Vollmer <marius.vollmer@uni-dortmund.de>]

rm@fabula.de writes:

> > Why do you want to perform module system operations from C?  Maybe
> > there is a more elegant way.
> 
> Ok this is for my current (frankensteinish) hacking with Dave's mod_guile:
> i'm working on implementing a mod_guile mode in which URLs get mapped to
> so-called 'handlers' in modules - meaning i (ab?)use the hierarchical module
> space a namespace enclosures.

That sounds rather reasonable to me.  But do you need to invoke
'use-modules' for this?

What I would probably do is to have a single Scheme function that gets
called from C, and perform all the dispatching in Scheme.  That
function would be called with different arguments for different
<Location>s.

I suppose, all Apache can really handle in its configuration file are
strings.  So I would make my Scheme function take a string as its
argument.  When the function wants to interpret that string as a
Scheme form, it can do so.  (Calling 'read' from Scheme is no less
efficient than calling it from C, but more convenient.)

Maybe I would even require the Scheme code to register the dispatching
function with the C code before it can be used.  That way, the C code
is completely independent from the Scheme code and the interactions
between the too are not via magic names but by explicit API calls.

> I'll also plan to add something like
> 
>  GuileBind a-symbol '(arbitrary (guile data) structure)
> 
> i.e. i want guile to 'read' from the configuration file and bind
> 'a-symbol' to whatever was read.

I think I would pass extra information via the handler callback, not
as a variable, but of course I can't say whether that will be feasible
in your case.

> BTW, one reasons i do use the module system is the impicit cacheing i get:
> a module gets loaded only once, and that does make a difference in response
> time compared to the initial 'eval a file per request' aproach of mod_guile.

I see.  mod_guile should probably have a 'call a function per request'
kind of model.  That is just as flexible but does not have to be slow.

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel