httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From mi...@debella.aszi.sztaki.hu (Molnar Ingo)
Subject filter design
Date Fri, 30 Jun 2000 12:07:49 GMT

On Thu, 29 Jun 2000 rbb@covalent.net wrote:

> I've been focusing on the char * filters since the beginning. [...]

no, you have not. Please re-read your 'my conditions for removing my veto'
email:

  Message-ID: <Pine.LNX.4.21.0006281346100.24288-100000@koj.rkbloom.net>

most items you listed deal with wether Greg's filters can do zero-copy,
not 'char *' filters. Greg's sample filter solves all the zero-copy and
allocation issues you listed. Now that Greg has shown that zero-copy can
be done with his scheme just fine, you came up with another (unrelated)
list of requirements, and that is not fair. It really makes it appear as
if your real requirement was: 'it must be my all-buckets approach',
regardless of the facts.

'char *' filters in Greg's scheme are clearly a non-mandatory option
for quick prototype filters, conceptually slow filters or conceptually
non-zero-copy filters. You dont have to use 'char *' filters. An
all-buckets filter chain will zero-copy, period.

If a filter in the chain is non-zero-copy, then there will be one more
copy, so what? If it's eg. a compression filter then there can be no
zero-copy *mathematically*, because the transformation done in the
filter is nonlinear. It's a business of that filter, and *if* it can
conceptually be zero-copy then someone will rewrite it to be bucket
based. Q.E.D.

	Ingo

ps. as a sidenote, i believe it's unethical to veto a patch when the
vetoer has a 'competing' patch for the same problem as well. The
'competitor' is of course free to point out suspected design flaws,
but should not use her voting power in a negative way in that matter.


Mime
View raw message