httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Roy T. Fielding" <field...@kiwi.ICS.UCI.EDU>
Subject Re: Filtering issues.
Date Thu, 13 Jul 2000 01:39:52 GMT
>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.

>Conversely: you designed for the 5% solution and force the other 95% to
>conform to that solution. You must memcpy() data into arbitrary-lifetime

That isn't an aspect of the design.

>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.

Please, I am tired of this type of discussion.  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 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.

>The solution that you're putting together feels very complex and very

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.

>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.

>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.

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.


View raw message