Re: the three filter types (was: cvs commit: httpd-2.0/server core.c)

[Greg Stein]

On Mon, Mar 04, 2002 at 08:35:35PM -0800, Ryan Bloom wrote:
  On Sun, Mar 03, 2002 at 10:34:55PM -, [EMAIL PROTECTED] 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
 
 YES, resource is markedly better than CONTENT.  I have been using
 resource all day when explaining this to people at work.  Always scary
 when Greg and I agree.  :-)

Oh, for christssakes... put up some kind of argument...

;-)

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

RE: the three filter types (was: cvs commit: httpd-2.0/server core.c)

[Ryan Bloom]

 On Sun, Mar 03, 2002 at 10:34:55PM -, [EMAIL PROTECTED] wrote:
  rbb 02/03/03 14:34:55
 
Modified:modules/http http_core.c
 server   core.c
Log:
Classify some of the input filters as the correct types.  Previous
to
this patch, the type wasn't too important, because all filters
were
put on the same list.  After this patch, the filter type is very
 important,
because there are three different types of filters, and they are
all
 treated
differently, namely:
 
CONNECTION:   Filters of this type are valid for the lifetime
of this
  connection.
PROTOCOL: Filters of this type are valid for the lifetime of this
  request from the point of view of the client, this means
  that the request is valid from the time that the request
  is sent until the time that the response is received.
CONTENT:  Filters of this type are valid for the time that this
  content is used to satisfy a request.  For simple
requests,
  this is identical to PROTOCOL, but internal redirects
  and sub-requests can change the content without ending
  the request.
 
 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

YES, resource is markedly better than CONTENT.  I have been using
resource all day when explaining this to people at work.  Always scary
when Greg and I agree.  :-)

Ryan

Re: the three filter types (was: cvs commit: httpd-2.0/server core.c)

[William A. Rowe, Jr.]

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