Re: the three filter types

[Greg Stein <gs...@lyra.org>]

On Mon, Mar 04, 2002 at 11:13:29PM -0600, William A. Rowe, Jr. wrote:
> 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.

In HTTP, it is a resource you're make a request against. The body and
content are aspects of the protocol (the "message", in particular).

> 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],

The protocol is *not* defined by the resource. It is defined by the
underlying connection. My client is connecting to the server with a
particular protocol. The resource that I talk to has *nothing* to do with
that.

> but we can munge together
> a bunch of 'resource' streams into one 'request' [as once defined in 1.3 :-]

Yup. For instance, a PROPFIND returning data from many resources (mod_dav
defines a "walk" API over resources to do this).

SSI allows you to incorporate multiple resources, but this is tricky ground.
There are public resources, and then there are resources that could be
entirely private to the server (such as a CGI invoked only thru SSI, but it
doesn't have a URL associated with it). The distinction could be important.

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

No, the protocol adjusts itself based on characteristics of the resource and
what the client requested. For example, with .gz, the protocol sees the
"Accept-Encoding" and turns on the compression. But the protocl might also
look at the resource's type and say, "hmm. it's a jpeg. that isn't going to
compress."

Point is: the resource is strictly hidden from protocol concerns.

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

Holy crap. I'm not talking about taking out Location. That is the whole key
to the mechanism!

You lay out your URL space (e.g. Location directives) into a tree in memory.
At each node, you hang configuration elements, a hash table pointing to
child nodes, and a resource provider for that node and its children (of
course, unless overridden by a provider statement below that point).

> 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 :)

I have never agreed with the concept of discouraging the Location directive.
The Location directives, and the implicit tree ("namespace") it defines are
how a user sees the site.

The Directory directive is looking at your server from the wrong direction.

Essentially, you lay out your URL space using Location and other directives
which define locations (Alias, for example; it defines a location which maps
to a directory). The Directory is then used to establish details about the
underlying filesystem, but it is *totally* independent of the Location tree.

  /
    subtree1/
       subsub/
    subtree2/
       subthree/

The location tree might look like something above, and it has "providers"
associated with different points on that tree. Usually, it will be the
default filesystem provider. The filesystem provider has its own tree of
configuration data, as applied to the content in the filesystem.

  /home/www/docroot/
     group1/
       subsub/
     subtree2/
     group3/

The configuration associated with the Directory directive is stored in this
tree, not in the Location tree.

When the system walks down the location tree to the target resource, it asks
the provider for additional config (beyond what may be hooked into the
location tree). That is where the filesystem provider can return the config
associated with elements in its tree (based on whatever the Location node
happened to map to in its tre).

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

Have no fear. The above has only been Blue Sky. Greg's Desired Resource
Model. :-)

Please return to your regularly scheduled program...

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/