please remove user from list

[Charles Cutler <ch...@ruadh.com>]

please remove this user from list

___________________________________________

Charles Cutler
Ruadh Ltd
Tel - 00 44 (0)1334 654300
charles@ruadh.com
http://www.ruadh.com

-----Original Message-----
From: rbb@covalent.net [mailto:rbb@covalent.net]
Sent: 22 June 2000 15:48
To: new-httpd@apache.org
Subject: Re: PLEASE READ: Filter I/O



> Sorry, but I have to give a -1 again.
>
> I realize how this is really holding up the filtering concept, so I feel a
> big reponsibility to provide real, working code for the alternative
scheme.
> I'm putting the mod_dav integration on hold until I code up a patch for
the
> link-based filtering. I feel it is a bit unfair to veto without coughing
up
> some code, so that'll be first priority for me.

I can not argue against a non existant patch.  I am not discussing this
anymore until I have seen a patch that implements the link based scheme.

Although I can't make any well reasoned arguments against this patch, I
can without a doubt make one against the design.  The recursive nature of
your design will slow this server to a crawl on some platforms.  Take a
look at the Sparc architecture.  This architecture uses register windows,
and these fall down when making recursive calls.

> Also, as I stated last week (before leaving for a few days of vacation),
I'm
> going to continue with some of the "common" items to simplify comparison
and
> review. I'll repost those items because I've got some questions/concerns
for
> people to comment on.

I have already veto'ed all of those patches.  If you want a technical
reason, here it is.  As I have already proven with my last patch, these
changes are completely bogus unless we use the link based scheme.  The
function that you created in your last patch to do this stuff is
completely unnecessary and adds a wasted function call when using the hook
based scheme.  These "common" things that you want to change have VERY
different solutions based on which scheme is chosen finally.  The patch I
submitted yesterday rips your last "common" change out completely.  At the
very least do not commit until the changes have been posted first.  This
way I can give valid technical reasons for why those common changes aren't
common at all.

Ryan

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