httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ben Hyde <bh...@pobox.com>
Subject Re: canonical list of i/o layering use cases
Date Tue, 28 Mar 2000 14:39:34 GMT
Dean Gaudet <dgaudet-list-new-httpd@arctic.org> writes:
> please to submit more filters/sources/sinks i haven't considered yet.

:-)

This discussion flairs up from time to time, doesn't it!

The last time this flared up I came to the opinion that
there is a knot here worth illuminating, but I can't recall
if I bothered to say it outloud here.

The inside of the knot is: planning, authorizing, executing.

The request arrives and the beast has to assemble a plan for
how to respond.  These plans can, and ought to be, reasonably
ornate; at least a tree.  The primitive nodes are things like
stream this file, do this character set conversion, etc.  The
slightly more complex nodes do things like store results in
caches, and assemble bits into bundles, etc.  The core ought
to provide a way to manipulate these plans.  The types of nodes
and the operation sets on them should be provided by modules.

Given the plan then the problem is to decide if this is approprate
to execute it.  I.e. do we have all the rights we need.  This is
a mess because it needs to draw information from three domains,
the client's credentials, the process/thread rights, and the 
protection configuration on the named objects that are inputs to
the plan.

Finally execution.  The execution is where we start wanting
terrific efficencies.  Zero copy, clever caching, kernel hackery,
levering O/S specific delights like sendfile.

The outside of the knot of plan/auth/exec is the necessity of
letting all three phases spread across machines, processes, threads,
code cult, and projects.  (This is why that www.spread.org work is 
so right on).

I suspect it was at about this point in my thinking that I become
happy that this was slipping outside the scope of 2.0 where it
could stew longer.

 - ben

Mime
View raw message