httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <gst...@lyra.org>
Subject Re: Filtering issues.
Date Thu, 13 Jul 2000 02:19:17 GMT
On Wed, Jul 12, 2000 at 06:39:52PM -0700, Roy T. Fielding wrote:
> >My filter design considers the 95% case: no memcpy() is needed *unless*
> >somebody desides to "set aside" the output.
> 
> You can do that with buckets as well -- just create a bucket type that
> has to be replicated when set aside.

Exactly! That is how my patch/design approaches the problem. I'm trying to
say that the code that Ryan as submitted takes the opposite approach: all
buckets must be self-determining so they can be set aside.

> >Conversely: you designed for the 5% solution and force the other 95% to
> >conform to that solution. You must memcpy() data into arbitrary-lifetime
> >buffers.
> 
> That isn't an aspect of the design.

As I understand Ryan's patch: yes, it is.

> >You say "most content generators will need to be re-written to take full
> >advantage of the optimizations available to filters, ..."  Well, that is an
> >aspect of your design. My filter design does not require *any* content
> >generators to be rewritten.
> 
> Your design will never be optimal, period.  That's why we can't start
> with it as a basis, even if it works.

You have not explained what is sub-optimal about my patch. Please do so. How
can I get it improved to "your specifications" unless you help here?

> Please, I am tired of this type of discussion.

And I'm getting a bit tired of your "bring me a rock" messages. "Roy, here
is a patch." "Nope. That's not it." "Roy, here is another." "Nope, that
doesn't work either."

You keep saying that there is something wrong with the two patches, but you
haven't explained *what*. How can we fix anything?

> There are valid bits of
> stuff in all the files committed, and the only way to get to an optimal
> solution is to stop talking about "my" patch and start filling out the
> holes in the implementations of the design.

> If there are problems with the code, in any of the files, then commit
> a comment to that effect directly within the code or within a design
> overview doc in the same directory.

I don't believe in the approach/design that Ryan has embodied in his
implementation. I've explained why. I don't have any particular motivation
to try and correct the stuff that he has written, when I believe there is
*already* a perfectively viable alternative prepared and ready to go (for a
week and a half now). And as far as I'm concerned, these are still suggested
patches and they have names attached; I'll continue to refer to them by
name. See ap_filter.h for the design embodied in my patches. If it is
missing some information that you'd like to see, then please ask.

And I haven't heard anything but hand-waving about why the bucket design and
lifetime issues in my patch are "bad" or "wrong" or "never be optimal." I
just don't believe it at this time. Stop talking about it and show us the
"right" code or describe the "right" design that enables filtering in
today's Apache, without changes being required from content generators.
Whatever the solution is, it should be able to drop right in. If you have
different requirements, then let's hear them.

> >I am quite interested watching the development of the buckets now that you
> >placed them into source control. There does not seem to be a coherent design
> >that is managing the development. A lot of poking, prodding, and bug fixing
> >is occurring to get the stuff to work. I find that very sad when there is an
> >existing filtering patch that doesn't have these bugs, works very well, does
> >not impose changes upon the content generators, etc.
> 
> And doesn't satisfy our needs.

WHY? Don't just sit there and say "no" without explanation. That is
counter-productive.

> >The solution that you're putting together feels very complex and very
> >fragile.
> 
> I agree, but that is because it doesn't fit the design yet.  That's my
> problem to fix and it isn't something I can do without access to all of
> the source files.

What design? And why is it only your problem?

If you're participating, then help us out here. It's very annoying to get
pronouncements from on high. Summarize your requirements, and then match
those up against the two patch sets. I'd be interested to know what you're
looking for, and how the patch sets fail those expectations. As it stands,
we are simply bringing rocks to the table.

> >I chuckled when I saw the addition of the "rmem" buckets and that you simply
> >stored the pointer into the bucket. Your bucket design requires buckets'
> >lifetimes to be self-determining, so a simple reference would never work.
> >You will always need to copy, so those rmem buckets simply do not work.
> 
> Fix it, or make a note and someone else will fix it.

I already fixed it -- by virtue of the problem not being present in my
patches. Why should I spend time creating/fixing/patching/documenting
duplicate, broken code? Please explain why.

> >Finally, a meta issue: it is rather upsetting that vetoed code is residing
> >in APR. People are submitting patches to get the darn thing to compile, to
> >fix bugs, and add functions. I feel the process that is happening around
> >this bucket stuff is not respecting the Apache Development Guidelines.
> 
> Voting is used to determine what gets distributed as Apache, not what
> resides in the repository.  The repository is a development tool.

As it stands, Ryan has added it to Apache. That is the problem. I could care
less that it sits there.

> The guidelines are designed to help us make progress on decisions.
> When two developers are deadlocked in consideration of an issue, the
> right way to resolve the deadlock is via a bake-off, where both designs
> are implemented and we all test to see which works best.  Then we can
> vote on the implementation and not on the design.

Fine. What is your suggested process? I've got an implementation that is
ready for review. Has been for a while. What process are you suggesting that
will magically get it reviewed? Or do we first sit around until all the
implementations arrive? Does this stuff never go into Apache because nobody
cares to do the reviews you're looking for?

Grumbly,
-g

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

Mime
View raw message