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 13 :-]
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 21, 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 20 :) Let's get planning for 21 - ROADMAP is calling
Good thoughts Greg;
Bill