httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Ames <>
Subject Re: cvs commit: apache-2.0/src/main http_protocol.c
Date Fri, 13 Oct 2000 15:24:39 GMT wrote:
>        Passing brigades in two directions may be possible, IFF we use
> function arguments to pass the brigades.  

Good.  Sounds like you are starting to open your mind to the possibility
that there might be more than the One True Solution.

>                  The original
> patch that you and Jeff created had two filters storing things in the
> conn_rec structure.  

                     .....a quick hack to demonstrate the concept,
inspired by 
c->input_data, c->remaining, etc...

>             But the problem is that it is impossible to know who
> stored the data there are why.  To do that requires state, which wasn't
> implemented, and would get ugly quickly. I guess we also need to get rid of r->content_type,
c->input_filters, etc,
because some night mod_speling might wake up and store the wrong stuff
there without leaving any tracks.  sheesh....  I'm not going to loose
any sleep over that one, trust me.

The point is that it is possible to have fields in structures shared
between multiple pieces of code as long as everybody plays by the
rules.  And we have the power to make up the rules for new stuff.  Yup,
information hiding is wonderful because less shared data mean less rules
to invent/follow, but it can slow you down when you're in prototype

> The problem with passing data back through arguments, is that you don't
> know which filters have been called already.  Think of it this way.  We
> have a gunzip filter, which takes a bunch of compressed body data, and
> uncompresses it.  Now, a higher filter decides to pass that data back
> down, if it goes through the uncompress filter, then that filter can stop
> the pass-back, but wait what if the data need to  go further than the
> uncompress filter.  

no, no, NO, no, no...the unget/unread concept works between two adjacent
filters.  And if the data passed on unread looks any different that the
data you read (other than having some bytes lopped off the front end),
you better know what the heck you are doing.  

> Passing data in one direction works because the filter says "I am done, I
> never need to see this again".  

unread says "Dang! I tried to take a little sip from the fire hose, and
it just didn't work out for me.  Here's some of your data back."

> > I think this is OK for now, but the global argument passing thing is
> > pretty shaky.  Sure, I love the concept of parameters.  But since we
> > don't have a clean way today to target a specific filter with a specific
> > dynamic parameter, the "one length argument applies to all filters"
> > approach means that we can't implement any input filters that increase
> > the length of the content.  

I didn't articulate my concern here very well the first time around. 
The length expansion argument was just meant as an example of what could
go wrong with passing http_filter's unique protocol data parameter to
every possible input filter that could ever be written, and expect it to
make sense.  

I'm really OK with c->remaining for now.  It allows us to make forward
progress toward a beta, and may prevent yet another "Greg vs. Ryan
Filter Design Jihad via Email" (different Greg of course).  I'm also OK
if we can come up with a cooler, really fast way to pass this parm just
to http_filter, and no other filter.  

The object of having our favorite length field be a parameter vs. a
field in the c is information hiding (please correct me if I'm wrong,
Mr. Stein).  But passing it as a parm to every input filter rather than
just http_filter isn't hiding the information, is it? 


View raw message