Return-Path: <new-httpd-owner-new-httpd-archive=hyperreal.org@apache.org>
Delivered-To: new-httpd-archive@hyperreal.org
Received: (qmail 24759 invoked by uid 6000); 3 Jan 1999 21:33:19 -0000
Received: (qmail 24752 invoked from network); 3 Jan 1999 21:33:18 -0000
Received: from elaine34.stanford.edu (171.64.15.109)
  by taz.hyperreal.org with SMTP; 3 Jan 1999 21:33:18 -0000
Received: (from akosut@localhost)
	by elaine34.Stanford.EDU (8.8.8/8.8.7) id NAA17063;
	Sun, 3 Jan 1999 13:33:12 -0800 (PST)
Date: Sun, 3 Jan 1999 13:33:12 -0800 (PST)
From: Alexei Kosut <akosut@leland.Stanford.EDU>
To: new-httpd@apache.org
Subject: Re: more wacky A2 ideas
In-Reply-To: <368FC874.9C4F302@algroup.co.uk>
Message-ID: <Pine.GSO.3.96.990103132416.16742A-100000@elaine34.Stanford.EDU>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: new-httpd-owner@apache.org
Precedence: bulk
Reply-To: new-httpd@apache.org

On Sun, 3 Jan 1999, Ben Laurie wrote:

> I'm obviously missing something - clearly _something_ knows about files.
> All we need to do (All? Hah!) is push the file-dependent stuff down into
> the file module (which is where it belongs anyway, right?).

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...

> > URI-to-LRI ^/imagemaps/(.*) file-data-store("$1") imap-filter("CERN")
> > 
> > URI-to-LRI ^/html(.*) file-data-store("/usr/www/htdocs$1")
> 
> I find the lack of slashes here disconcerting. Was it deliberate?

I suppose. The exact syntax isn't terribly concerning to me right now.

> 
> > <LRI file-data-store *> > AddHandler server-side-includes shtml
> > AddFilterToLRIByHandler server-side-includes includes-filter()
> > </LRI>
> 
> Bong! shtml is an extension, but * matches an opaque string, no? Or is
> it sufficiently unopaque that we are going to believe in "extensions"?

Oh. Good point. Yeah, I guess extensions are a file-based thing. Those go
in the file module too, I guess (makes it an interesting exercise to
figure out how negotiation works, though - who gets to pick the variant,
the core or the data store. It should be the core, but that means we need
a mechanism for the data store to say "well, I've got eight
representations of this object - which one do you want?" to the core.  It
may mean you need three representations of each resource: the URI, the
data store+all object variants, and the LRI (i.e., the chosen resource +
filters). Ergh.)

No, wait... AddHandler is probably a configuration directive of the file
data store. That would make sense - it'd be illegal to use it inside of an
<LRI oracle-db> section, but in an <LRI file-data-store> section, it's
valid, yes?

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