httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexei Kosut <ako...@leland.Stanford.EDU>
Subject Re: more wacky A2 ideas
Date Sun, 03 Jan 1999 21:43:45 GMT
On Sun, 3 Jan 1999, Alexei Kosut wrote:

> Okay, I know what you're missing. This is what I was talking about in my
> initial message - yes, something needs to know about files. And putting
> that all into the filesystem data store was my first inclination, too. But
> how do you do CGIs then? You can't make them a filter (at least, I've
> never heard of an OS that supports streamed executables); they really
> should be their own data store. But they also need to behave exactly like
> files...

After sending this, I thought of one possible solution: The problem is
that we have multiple data stores (the equivilent of probably 80% of the
A1 modules today) that all share exactly the same characteristics dealing
with the file system, except one: actually turning the file on disk into
content. The metadata (extension), permissions, config (htaccess) stuff is
all identical. So why not give the file data store modules of its own? 
A1's 'handler' phase concept is perfect for this. Allow the file data
store to configure each of its LRIs with a handler (probably by LRI or
extension, like we do today), and add modules to the file data store to
actually serve them. They'd be passed a filename/fd and an output stream
(of whatever sort), and they could serve it up straight, or execute it
somehow, or parse it, or whatnot.

I kind of like this solution, it has a certain elegance... Heck, maybe we
could even use the A1 API (or a subset) as the API for file data store
modules. It fits pretty well to what I'm thinking.

-- Alexei Kosut <akosut@stanford.edu> <http://www.stanford.edu/~akosut/>
   Stanford University, Class of 2001 * Apache <http://www.apache.org> *



Mime
View raw message