> On Sat, Apr 07, 2001 at 08:54:51PM -0500, William A. Rowe, Jr. wrote:
> >...
> > For 2.1 (or 3.0) this nonsense must change. If I say <Location /> SetHandler
>SQLSpace-handler
> > then the entire file-system part of httpd needs to just _disappear_.
>
> You got that right. After doing the stuff for mod_dav's arbitrary backends,
> I've been thinking on the right form for Apache for quite a while. Rather
> than respond to the items in your post, I'll briefly explain how I believe
> we should be doing the processing:
>
I don't grok this explanation...
> Apache would keep a tree which corresponds to the URL space.
When is this tree built? At server start or dynamically? Based on what directives?
Location? Alias?
Rewrite rules? A simple first approach (and perhaps the only approach) is to define
the URL space
as being -defined- by Location directives.
> The root of
> the tree corresponds to "/" on the virtual server. Children of each node
> are a hash table, keyed by the URI component. Nodes only exist where
> configuration has occurred -- the node configuration typically means
> children exist, but they simply aren't part of the URL-space tree.
>
Please give a simple example :-)
> One of the config options at a node is a directory/file path (the Alias
> directive). Alternatively, the node could point to a database of
> content, or to a custom module, or whatever. The basic point is that
> each node says "<this> function/module/handler specifies the URL space
> for my children (which are not explicitly listed in the node's
> children)." (note: it only translates URLs into an internal resource
> identifier; the handler for a resource is still separate)
>
> Thus, if we see /foo, the system looks at the tree, finds "/" and that
> it is mapped to DIR in the filesystem. However, we also see "foo" as a
> child, so we go to that node. That node points to a custom module for
> that space. If we see "/bar", then we do a directory walk to bar.
>
> I believe that we'd want to look for a .htaccess in "/" since that *is*
> the parent resource of /foo, even though /foo is handled special (it may
> want to establish security policy for everything in "/"). Of course, the
> config for "/" could disable .htaccess files.
>
> etc.
>
> Having the tree in memory means that we can quickly map a URL to a resource.
> Currently, we have linear lists of directories, locations, and files that we
> need to scan. The tree is also much nicer from an introspection point -- we
> can navigate it to discover what the URL space looks like. This is actually
> a HUGE bonus for DAV's PROPFIND method. At the moment, I return results for
> a PROPFIND based on what I see in the filesystem (imagine PROPFIND to be an
> "ls" for the web server). If somebody has attached some kind of URL space in
> there, the PROPFIND doesn't return it. However, with the tree, I can see
> those children and return results for them.
>
> The trees would be per-server, and (sub)trees could be shared.
>
> But whatever... this is a big restructuring best left post-2.0.
>
> Cheers,
> -g
>
> --
> Greg Stein, http://www.lyra.org/
>
