[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Mod-guile-devel] Autoconf files
|
From: |
rm |
|
Subject: |
Re: [Mod-guile-devel] Autoconf files |
|
Date: |
Sun, 28 Jul 2002 11:07:00 +0200 |
|
User-agent: |
Mutt/1.3.24i |
On Sat, Jul 27, 2002 at 11:10:49PM -0400, Dale P. Smith wrote:
>
> The current method of just load'ing .scm files was just so I could get
> something going. I actually want to make mod_guile flexible enough to
> do just about anything. The current mg_scm_handler needs to be written
> in scheme and a good way of abstracting it so other kinds of handlers
> could be written easily.
>
Yes, that was my idea with a generic 'guile-handler'. That way one
can easily add more/new ways of request processing to mod_guile.
This is pretty much the wa mod_perl does it.
> I see a whole spectrum of scheme-enabled web pages. There is the basic
> html with a little bit of scheme thrown in here or there, possibly
> written using a gui web development tool. There is just raw scheme that
> uses display to generate html. How about something like a scheme based
> markup language? Like laml or some of the stuff that address@hidden has
> done. I'd like to see handlers for all of these, or rather, I'd like
> the hooks to be there so that these (and any other) handlers are easy to
> write.
>
> At any rate, I was planning to at least have some kind of caching of
> .scm files to speed things up. The .scm file would only be re-read if it
> changed.
I wounder whether it's worth the time. The kind of 'FastCGI' approach
(let's call it guile-script for now) is usually used on low to medium
load websites -- the time to read a guile script most likely can be
neglected.
> I also don't like the idea of passing the request rec in the
> Request global variable. Ugh! But .sch files don't really have
> arguments. There are lot's of questions on how to go about doing these
> things, and I was getting stuck. I was hoping wiser and more
> experienced people could offer suggestions and insight. ;^)
Again, the mod_perl way (and i think it is a rather elegant way)
is: a handler is just a function of arity 1 that gets the request
passed as its only parameter and that is supposed to return a result
code (int). mod_perl (ab)uses perl's module system as a way to control
namespace. A configuration directive like
SetHandler perl-handler
PerlHandler Ralf::Shop::Catalog
will tell mod_perl to call the function 'handler' from the
'Ralf::Shop::Catalog' module. As an optional second parameter
i could specify the name of the function to call, in case i
want to put more than one handler into the same module.
So i'd suggest having a similar approach in mod_guile: a apache
configuration directive 'GuileHandler' that takes as its parameter
either a list (-> module from which the function 'handler' gets called)
or a pair of the form (list . symbol) wich gives the module and the
name of the function to call. So a sample handler file would look
something like this:
*-----------------------------------------------------------------
|
| ;; file samples/dump-request.scm
|
| (define-module (sample dump-request)
| #:export (handler))
|
| ;; Since interesting-values isn't exported it doesn't
| ;; clutter the global namespace. This would solve your
| ;; concerns about unintentional catching of bindings from
| ;; other handlers/scripts.
|
| (define interesting-values '(remote-host path-info server))
|
| ;; And since define is executed only once during module
| ;; loading, we get some kind of cacheing here for free.
|
| (define expensive-data (query-do-database-on mars))
|
| ;; our handler function
| (define (handler the-request)
| (display "<html><head><title>Request Dump</title></head><body>")
|
| (for-each (lambda (thingy)
| (format #t "~A -> ~A <br>" thingy (get-value the-request thingy)))
| interesting-values)
|
| (display "</body></html>"))
|
In httpd.conf:
<Location /whereever/dump>
SetHandler guile-handler
GuileHanlder (samples dump)
# or, if we want to be explicit
GuileHandler ((samples dump) . handler)
</Location>
> > Oh, i also would suggest adding a 'guile-script-handler'. I have mo-
> > dified mod_guile.c that way, so one can do the following:
> >
> > <Location /guile-scripts>
> > AddHandler guile-script-handler
of course, this should read:
SetHandler guile-script-handler
>
> Yes. Have you ever looked as quixote? It's in Python, not Scheme, but
> there are some ideas in there that are ver interesting. Like the way
> the module namespace and the url name space sort of blend together.
I had a brief look at it (when i do webwork in Python it's usually
in Zope): that's another way of combining the URL hierachical namespace
and the module system. I think some Java Servlet engines do the same
with the class hierarchy.
For now i'd stay away from it: for me there are still some questions
with this approach -- guile's module space is hierachical 'by accident',
it doesn't carry _any_ semantic meaning. Module (foo bar) doesn't inherit
or share a namespace with module (foo), for example. Maybe something
like Zope's tree of _objects_ (rather than classes/modules) would be
more appropriate. But for that we'd probably need a way to save an
object tree to disk ... more work for the guile comunity ;-)
Oh, and of course we all need to wait for the module<->goops integration.
Ralf