httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From r..@covalent.net
Subject Re: challenge requirements (was: summary: issues for my filtering patch)
Date Wed, 28 Jun 2000 22:04:27 GMT

> > I would much prefer an actual module that actually compiles and caches the
> > response.  If it doesn't actually change the headers that are sent, but
> > does make the ap_set_header call, then I will be fine with that.
> 
> I'll see what I can do. If it starts to add too much to the current patch,
> then I'll come back. Again: I'd like to keep the original patch slim for
> wider reviewability, your requested module as a future change, and the
> support for that module another future change.

I agree, keep the current patch as simple as possible.  

> IOW, is it fair to state that the current patch can go in *without* this
> particular module/support structure? That simply showing that your challenge
> is possible, will validate that the current patch can support it?

Maybe.  If you design ten new structures that are pretty complex, no.  If
you design two or three obvious structures to support this, then of course
this doesn't need to be rolled into the current patch.  Basically what I
am saying is that if supporting this means changing the current patch
drastically, then the current patch isn't the right patch.  Make
sense?  do you agree?

> > The bucket brigade scheme does not force ap_rwrite(), ap_rputs to allocate
> > any memory, but for the time being, let's ignore that.
> 
> Any scheme does since the char* passed to ap_rwrite() has an unknown
> lifetime. It *must* be copied *if* you want to change its lifetime.

Ahhhh.  But, the bucket brigades don't always change an object's
lifetime.  When dealing with a char *, ap_rwrite/ap_rputs/... will either
allocate memory or not, based on which type of bucket is being created.  I
should have specified that.

> The bucket brigade can say "here is a string, it will die when you return."
> Your request here is to *also* allow the framework to say "here is a string,
> keep it if you'd like... it will survive until you say otherwise."
> 
> Agreed?

Essentially.  The way I see the bucket brigades, they say "Here's a
string, it will die when you no longer need it, don't worry about
how."  The framework then makes that happen.  I see how this is done, but
trying to explain it without code would be hard.  I'll be starting the new
patch sometime later this week/early next week.  I am not coding filtering
for a few days.  :-)

BTW, the bucket brigades that I am talking about here are my
interpretation of what Roy is talking about.  I may not see the same thing
he does.  I think we all know communicating through e-mail isn't always
the clearest thing in the world.

> This is just a quick read through. I may come back when I dig in.

Please come back as much as you need to.  Fair warning.  I have guests
tonight.  I am stopping work after they have toured the city.  Once I stop
for the day, I'm unlikely to check e-mail until tomorrow morning.  I'll
answer your questions as soon as I get them though.

> > 2)  No memory can be allocated out of r->pool.  If it is allocated out of
> > r->pool, then the memory must be allocated for the length of the
> > request.  Sub-pools are okay, but I will challenge them, and I will want a
> > very good piece of psuedo-code to explain why the sub-pool won't require
> > copying.
> 
> Agreed.
> 
> Note that r->pool and/or a subpool may be used to make a one-time allocation
> of a fixed-size value (i.e. not proportional to the response size). This
> should be okay. Agree?

I think so, but exactly what the buffer is used for may invalidate
that.  I know I am being unclear.  I am sorry about that.  Tell you
what, assume I agree with this.  If it turns out the memory allocation is
"bad", then I will be required to give both great docs and incredibly
psuedo-code or real code to prove it.  Sound fair?

> > 3)  It is assumed that the filter is the first filter in a chain of
> > filters.  ANY of the subsequent filters may also need to modify 
> > headers.  ANY of the subsequent filters may be either bucket or char *
> > type filters.
> 
> Agreed. I had assumed that.
> 
> Note that the subsequent filters are somewhat moot since this first filter
> is going to be holding back all the content until it is ready. When it
> finally releases it, then the next guys can do what they will.

Yes, BUT the next guy may want to actually modify the data.  If the next
filter wants to modify the data, it shouldn't have to copy the data to a
new buffer, and it should only allocate more memory if it wants to change
the size of the data or the current memory can't be modified.  Subsequent
filters are important to the design IMO, but they can be ignored most of
the time.

> > 4)  It would be nice although not required if this module was written
> > twice, once as a bucket type and once as a char *.  Because the two
> > filters have different purposes, this may not feasable.  I can understand
> > this.
> 
> The char* does not support this. You would not use a char* style of filter
> if you need to hold back the entire response.

OKAY.  I had thought so, but I thought I would check to be sure.  This is
why it was "gee that would be nice" not "you must do this to remove my
veto".  :-)

> > 5)  The filter doesn't have to actually modify anything, so the module
> > itself cannot allocate any memory to hold strings, except for structures
> > used to store the strings.
> 
> See (2). Some fixed amount of memory may be allocated.

Fine.

> > > If I provide the structures and detailed pseudo-code, will that be
> > > sufficient? I can do this today.
> > 
> > The more actual compile-able code there is, the better off we are.  One of
> > the arguments you have been making is that your patch can do 99% of this
> > today, as is.
> 
> Um. Then I was unclear. If I used the word "can", then I meant it in the
> future tense (i.e. "it can do that [with changes]"). Let's rephrase as "my
> patch could do this with straight-forward extensions."
> 
> Your "challenge" is in response to that statement :-). Fair enough.

My challenge is that if the current patch requires extensive changes to
make it do what we are talking about, the patch isn't "the right
solution".  If the changes are straight forward, and don't require months
to make, then I think that is fine.

> > In the end, my conditions may not be explained in enough detail.  I have
> > tried to think of everything, but I probably missed something.
> 
> That's all right. I understand the problem space ("hold the entire response,
> modify a header, release the response; zero copying occurs within the
> filter"). I'll write code to solve *that* problem. If that doesn't agree
> with you, then we can iterate.

GREAT!  Wait a second Greg, we are making progress again.  :-)

> Absolutely fair. Thanx.

Ain't it great when things just work.  :-)

Ryan

_______________________________________________________________________________
Ryan Bloom                        	rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------


Mime
View raw message