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;
Bill
