httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <>
Subject Re: the three filter types (was: cvs commit: httpd-2.0/server core.c)
Date Tue, 05 Mar 2002 05:13:29 GMT
At 07:53 PM 3/4/2002, you wrote:

>Just wanted to state that I believe Ryan has the correct distinction here --
>that we have three types of filters. However, the third type is a misnomer,
>and we can derive the proper name from the HTTP model: "resource"

Resource, body, content, whichever.  The trick is that any 'resource' can be
aggregated, while the connection filters are pretty fixed [or mutate in stable
ways, such as connection:upgrade semantics], protocol filters are pretty
fixed [they are designed by the top resource], but we can munge together
a bunch of 'resource' streams into one 'request' [as once defined in 1.3 :-]

>In HTTP, you talk to a resource on the server. With our redirect stuff, all
>we're doing is pointing to a different resource. The connection and protocol
>remain the same.

Bingo, for the most part.  Absolutely on when it comes to merging several
resources [sub-requests].  Only thing is that which resource will have some
thing to do with the protocol (want the .gz flavor?  here it is...)

>In Apache 2.1, I'd like to move towards the resource model, and also create
>a resource mapping tree. Rather than this whole "location / directory" walk
>crap, we navigate down a tree. Each node identifies a different provider of
>resources. The root node ("/") refers to the filesystem provider, keyed in
>at DocumentRoot. The Alias directive creates new nodes in the location tree,
>also referring to the filesystem provider, but they point to a different
>space in the filesystem. etc etc.

You sort of describe what happened with map_to_storage ... directory only
applies to ... surprise ... files :)

I don't know if we can rip away Location altogether.  While it would be nice,
the location concept gives us some high-level abstractions, such as auth
contexts, etc, that are still relevant/useful.  But I would like to see us
continue to 'discourage' their use ... in so far as users 'presumed' the two
work the same.  URI space != file mounts :)

>Much of this resource model has already been fleshed out in mod_dav's
>dav_resource structure.

I need to study this, but I agree that replacing the filesystem altogether with
a dav-like provider model is the only way to move forward.

But not for release 2.0 :)  Let's get planning for 2.1 - ROADMAP is calling.

Good thoughts Greg;


View raw message