[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: scm_* API extension? [was] scm_* API question
From: |
rm |
Subject: |
Re: scm_* API extension? [was] scm_* API question |
Date: |
Thu, 1 Aug 2002 12:10:15 +0200 |
User-agent: |
Mutt/1.3.24i |
On Wed, Jul 31, 2002 at 04:59:35PM -0500, Rob Browning wrote:
[ nice samples removed ]
>
> etc. There's also a module-ref function and a module-use! function...
I konw these, but this is all done from the scheme side. I just want
to be able to do the same cool things from C (other than scm_call_*ing
the functions from (ice-9 safe) etc.).
> > 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.
>
> Well that may or may not be the right thing to do if you're *just*
> using the module system for the caching. In that case, you may be
> better off to implement the caching yourself (via a hash table or
> whatever) and leave the module system to more static modules.
No, cacheing is just a (very) nice side effect. My main rationale is
the namespace encapsulation. In general i think these modules should
be considered static -- during the lifetime of a server the code for
a handler shouldn't change. I put things like 'GuileBind ... ' into
the handler's module since i haven't understood how to do the same
with environments so far.
> For example, depending on what you're wanting to do, you might want to
> allow different requests to be handled inside separate namespaces,
> though they're all using a common set of code. OTTOMH, I think you
> could do this by putting the common functionality into a module, say
> foo.scm, then doing something like this for *each* request:
>
> (use-modules (foo))
> (define foo-module (resolve-module '(foo)))
>
> ;; For each request...
> (define next-request-envt (make-safe-module))
^ ^
| |
*----------------*
|
Does this mean: module <=> environment in guile?
> (module-use! next-request-envt (module-public-interface foo-module))
> (define request-form (list handler-sym current-url-string))
> (eval request-form next-request-envt)
>
> Marius, etc. Please correct any inaccuracies above -- I'm just going
> from what I've gathered while poking around. I suspect we need more
> thorough documentation of the acceptable usage of the anonymous module
> stuff.
Would be highly welcome ;-)
Ralf