Re: mod_guile, guile-latte, and other webstuff for guile...

[Jorgen 'forcer' Schaefer]

"Dale P. Smith" <address@hidden> writes:

> Jorgen 'forcer' Schaefer wrote:
> > 
> > Hi there!
> > I know i did quite a big fuzz about how I'm going to write
> > mod_guile.  That was back when i used to have a lot of time :( I'm
> > really sorry for that.  I'll not be able to complete it, but i
> > have a few good ideas about it.
> 
> I've been working on my own mod_guile for a while now.  You can write
> handlers in scheme that take a smobified request_rec as an argument. 
> Standard out is a port that uses ap_rwrite and friends.  Right now there
> are two hard-coded content handlers, scheme and "gbrl".   Scheme code is
> evaluated with gh_eval_file_with_catch.  Not nearly done, but it is
> working.
>
> I'd like to hear your ideas and what direction you were headed.

I put my working directory to
http://forcix.cx/programs/download/mod_guile.tar.gz ... it
contains an old tree and alot of other stuff.

I tried to implement request_rec is a port as well. 
I'll try to give a quick guide to my other ideas (which maybe
should be implemented in scheme or so, some of them):

- Handle MIME types of guile/*, call * function with request_rec
  (dunno if this is a good idea)
- Similar to mod_perl, a handler "guile" and a mod_guile specific
  config command which sets the scheme function to call
- A way to use a guile function as reader for some documents,
  e.g. it reads from the document, and returns scheme code which
  outputs the content of this page.  for normal CGI's in scheme,
  this would be (read).
- Load function which caches a file, e.g. load it into a
  (lambda () ...) construct, and just run it on each request.
  (similar to mod_perl; this might be obsoleted by the bytecompiler)
- request_rec port should check the Accept-Charset header from
  the client, and automagically transform guile's internal
  representation to a format the client can comprehend (there
  should be a way to deactivate or change this, too).  Don't
  forget to set the Content-type header appropriately.
- Security consideration (this might even be important for guile
  itself):  What to do with \0's in filenames?
  (string=? "/etc/passwd" "/etc/passwd\0foo") => #f
  (open-input-file "/etc/passwd\0foo") => #<input: /etc/passwd 3>

Take a look at
mod_guile/mod_guile_info
mod_guile/mod_guile/TODO
mod_guile/mod_guile/modules/IDEAS
mod_guile/mod_guile/TODO.guile-cgi
mod_guile/mod_guile/old/MailReply

And if you haven't, get yourself a copy of "Writing Apache
modules in Perl and C" -- very informative :) Also, reading about
Apache 2.0 was very interesting, and i think it would be nice to
design the module "portable".


> > Also, it would be nice if we could get BRL (or something like
> > BRL) on Guile. (which would result in possibilities like writing
> > BRL with Latte syntax... :)
> 
> I have a good deal of brl ported to guile, except I'm using
> "#>" for "]" and "<#" for "[".  Just one read-hash-extend and
> you don't have to patch guile!  The [ and ] are a *lot* cleaner
> looking though. :(

With my idea of the reader function as content handler, this
would be pretty easy.  We can even have <?scm ..?>, <%%>, <script
language="scheme"> etc., all distinguished by MIME types or such.
And when we have a language reader for PHP, we can directly
execute "legacy" PHP scripts.  And when we have a perl
rea... er... uhm... never mind ;)

> The sql-xxx functions are only using guile-pg.  It would really
> be nice if we had a common api for all the databases, like odbc
> or jdbc.

I think there was someone working on a unified SQL API for Guile,
or did that effort die?

The Squile API is pretty MySQL-centric, as i noticed, though i
hoped my rewrite for 2.0 was generic enough.  PostgreSQL seems
not to have a simple way to determine the type of a field, and
with user-defined types, the idea of auto-convertion is dead
anyways :(
        -- forcer

-- 
((email . "address@hidden")       (www . "http://forcix.cx/";)
 (irc   . "address@hidden (IRCnet)") (gpg .    "1024D/028AF63C"))