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 19:10:51 GMT
On Sun, 3 Jan 1999, Ben Laurie wrote:

> Hmmm ... perhaps I'm missing the point here, but wouldn't the point of
> an LRI be that it actually identified a resource, including, of course,
> a file. So I'd imagine that an LRI that referred to a file would looks
> something like "file:/a/b/c". Then a <Directory /x/y/z> directive maps
> neatly on to the (new) <LRI file:/x/y/z/.*> directive... and so on.

Probably. The problem I was thinking of was specifically htaccess files,
and a few others, which can't be solved in a generic manner.

> So "file:" LRIs do have some special properties (e.g. they know about
> symlinks) but they also have general ones ("directories").

Right. What I was referring to is that the same properties that the file
data store has to deal with, the CGI data store does as well, etc...; how
to produce all current Apache functionality with a model that knows
nothing about files does present some issues.

Especially if you want to promote other backing systems to the same level
as filesystems. i.e., if several data store modules are based on access to
an Oracle database, and that database is set up with certain properties,
e.g., the equivilent of file permissions, htaccess files, whichever, there
should be some way of sharing that code between data stores. The obvious
way to do that is just to have them both call the same functions, in a
library or something. Which is why I suggested doing it the same way for a
filesystem.

> Now the thing that exercises me is that LRIs may, in theory, map on to
> each other in mysterious ways. For example, URI:/x/y maps to
> LRI:sandwich:/a/b/y which maps to the concatenation of
> LRI:file:/a/b/header, LRI:file:/a/b/y, LRI:file:/a/b/footer. So what's
> the problem? Perhaps none, but at what points do the configuration rules
> apply in all this? Will configuring/debugging something like this drive
> everyone mad? Or will some kind of beautiful elegance drop out of the
> bottom?

I hope so. Simon was claiming he had some brilliant ideas on how to do
configuration for all this, but we haven't heard from him recently :)

I would say that "maps to the concatenation of" is probably not a function
of the server, but of a data store. i.e., a 'cat' data store module might
take a list of other LRIs, which it included (via a sub-request-like
mechanism).

An LRI, as I envision it, is the name of a data store module, an opaque
string to pass to that module, and a list of filters (with opaque strings
on those two) to apply to the output of the data store. That's
possibly simple enough to configure:

URI-to-LRI ^/imagemaps/(.*) file-data-store("$1") imap-filter("CERN")

URI-to-LRI ^/html(.*) file-data-store("/usr/www/htdocs$1")
<LRI file-data-store *>
AddHandler server-side-includes shtml
AddFilterToLRIByHandler server-side-includes includes-filter()
</LRI>

Or something.

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



Mime
View raw message