[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: mod_lisp for guile
From: |
Neil Jerram |
Subject: |
Re: mod_lisp for guile |
Date: |
Fri, 16 Sep 2005 19:46:27 +0100 |
User-agent: |
Gnus/5.1007 (Gnus v5.10.7) Emacs/21.4 (gnu/linux) |
Alan Grover <address@hidden> writes:
> Inspired by Guillaume Germain on the comp.lang.scheme group, I wrote a
> mod_lisp implementation for Guile. Find it at:
> https://sourceforge.net/project/showfiles.php?group_id=141512&package_id=163742
>
> I only implemented the mod_lisp protocol, leaving query-string/POST and
> HTML utilities for an external package (for example, TTN's www-guile). I
> did give in to weakness and provide an optional ability to create a
> thread for each request (did you know that "accept" blocks all threads?
> Yum.).
>
> It is minimally tested (it has an internal test daemon).
>
> I'd appreciate some feedback:
To be honest, I don't have that much to offer; but I know what it's
like when one posts to the list and gets no feedback at all, so here
goes ...
> * Will you use it?
I don't know. Currently whenever I want to add a Web interface to
a program, I just knock up the HTTP server infrastructure as part of
that program. But perhaps that's silly - would advantages would I get
from using mod_lisp instead?
> * Should I remove the thread-creation stuff and stick simply to mod_lisp
> protocol?
I don't understand what the mod_lisp protocol is, so can't really
comment. I'm interested in the architecture though - can you describe
it (or point me to reference)?
> * Should I provide an interface to integrate with TTN's www-guile?
How would that help? (Genuine question.)
> * How bad is the user-interface?
Do you mean the programming interface? (By UI I'd normally understand
something like a window or a command line, and AFAICS mod_lisp doesn't
have either of these.)
> * What do you think of providing a lazy-list of requests, rather than
> the current technique of passing control to a
> blocking-looping-function?
Don't understand enough yet to know! Please explain further.
> * Do you want to see a SRFI that provides _just_ the mod_lisp
> protocol?
Presumably you mean a SRFI defining a common Scheme API that people
could use to write code that plugs into your mod_lisp engine? (I
guess I'm missing the architecture again here.)
Regards,
Neil