Mailing-List: contact new-httpd-help@apache.org; run by ezmlm
Precedence: bulk
Reply-To: new-httpd@apache.org
Date: Wed, 29 Mar 2000 02:15:30 -0800 (PST)
From: "Jeffrey W. Baker" <jwbaker@acm.org>
Subject: Re: layered I/O (was: cvs commit: ...)
In-reply-to: <200003290205.aa19557@gremlin-relay.ics.uci.edu>
To: new-httpd@apache.org
Message-id: <Pine.LNX.4.21.0003290214210.10443-100000@piglet>
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset=US-ASCII

On Wed, 29 Mar 2000, Roy T. Fielding wrote:

> >Selection of IO Layers
> >
> >The core selects a source module and IO layers based on the urlspace
> >configuration.  Content might be generated by mod_perl, and the result is
> >piped through mod_chunk, mod_ssl, and mod_net, in turn.  When the content
> >generator runs, the core enforces that the module set the content type
> >before the first call to ap_bput.  The content type is set by a function
> >call.  The function (ap_set_content_type(request_rec *, char *)) examines
> >the content type and adds IO layers as neccessary.  For server parsed
> >html, the core might insert mod_include immediately after mod_perl.
> 
> The problem of thinking of it that way is that, like Dean mentioned,
> the output of one module may be filtered and the filter indicate that
> content should be embedded from another URL, which turns out to be a
> CGI script that outputs further parseable content.  In this instance,
> the goal of layered-IO is to abstract away such behavior so that the
> instance is processed recursively and thus doesn't result in some tangled
> mess of processing code for subrequests.  Doing it requires that each
> layer be able to pass both data and metadata, and have both data and
> metadata be processed at each layer (if desired), rather than call a
> single function that would set the metadata for the entire response.

Ah yes, module B produces output parsed by upstream module A, which never
even sees it.  I knew there must be a problem.

Shooting at drawing board.

jwb