httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Konstantin Chuguev <>
Subject Re: more wacky A2 ideas
Date Mon, 04 Jan 1999 07:57:25 GMT
Alexei Kosut wrote:
> 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.
IMO, there should be an abstract data store layer (module), offering
direct and/or sequential access to the raw data.
And various implementations based on this layer could be:
- file (more precisely, file system) data store - as now provided by A1
- database;
- HTTP/FTP/... client-side modules, getting raw data via various
  (A1 already has mod_proxy :-).

The way you process the raw data provided by those modules is not
with their internal functionality. I mean, you may want to use SHTML or
scripts stored both as files and in a database.
In the first case all you need is to obtain a FD for sequential access;
in the second one, you could ask the store layer to map temporarily a
executable to a file system in some way for direct access (which is
for execution).

	Konstantin V. Chuguev.		System administrator of Southern	Ural Regional Center of FREEnet,		Chelyabinsk, Russia.

View raw message