From: Graham Fawcett <address@hidden
>
Subject: [Chicken-users] Standard APIs for databases, Web-apps
I'd like to open discussion about introducing two formal APIs for use
in the development of future Chicken eggs: a standard API for
accessing relational databases
A DBI would be nice, though I wouldn't consider it a top priority, and it might not be worth the effort given the small size of our community and the other things we lack which may be more important. I'm ok with being married to Postgresql, at least for now. But if you want to do this, you might want to take a look at Gauche's DBI, new as of a few months ago:
http://www.kahua.org/cgi-bin/kahua.fcgi/kahua-web/show/dev/DBI(The Kahua project also has an ORM in a CLOS-like object system too, in case you're still interested in that).
On the Web front, I would love to see something like the WSGI proposal
that is current in the Python community. WSGI is somewhat analagous to
CGI (the interface, not the execution model): it's an in-process
contract between server-communication code on on side (scgi, fcgi,
tcp-server) and Web application code on the other. This decoupling
allows the vast sea of Python Web frameworks to share common Web
server bindings, and lets those frameworks share middleware components
(authentication, logging, content-validation, etc.) as well as
higher-level components from other frameworks.
Now you've got my attention. I'm already working on something like this. My idea is to have each backend (CGI, FastCGI, SCGI, mod_lisp, you typing in environment variables at a terminal, etc) return a record with an object representing what would be environment variables if it were a CGI process and an input, output, and error port. Output to the server would be done similarly to the WSGI way. A more friendly interface could then be built on top of this. I've nearly completed this for CGI and FastCGI (my implementation of which unfortunately has some serious problems..).
I don't claim that this is a 100% solution, but I lack the time and probably the judgement to come up with something much better. Hopefully it's at least a subset of a 90% solution.
I'm currently working on an SCGI adapter for Chicken; I'd like the
"inside" of this adapter to speak a WSGI-like protocol.
I was planning to start on an SCGI adapter myself. How is that going? We don't need two of them.
Ideally, I'd
like to help rework Spiffy's internals, so that it could speak the
common protocol, and decouple it from http-server at its dedicated
back-end. I'd be happy to discuss implementation details with anyone
who's interested.
Why would you want to use this with Spiffy? This protocol would be usable with faster and more mature servers like Apache and lighttpd without any extra work. Spiffy still has the advantage that you have greater control over it, but if you're using the protocol, aren't you giving that up anyway?