[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:
> 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.)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]