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: sick of this shit (was: Re: code chunks for filter challenge)
Date Fri, 30 Jun 2000 05:16:31 GMT
>Your veto is real bullshit. It is supported only by manufactured excuses,
>illogical assumptions, and impossible preconditions.

I don't think this is fair.  We don't need an interface that has all of
the problems of buff and is just as fragile as existing module writes
(more if you consider that the layers introduce configurable interaction
errors that simply didn't exist before).  If there is a design on the table
that can improve the situation, then not desiring an inferior design
is sufficient justification for a veto.  More to the point, if your
design doesn't significantly improve the state of our implementation,
then it isn't worth adding to the cruft to the server.

The char * interface cannot support sendfile or caching or writing a proxy
in filters.  It is useless to me, at the same cost as a design that would
actually work.  I'm not saying it isn't useful for someone -- I am saying
the design won't accomplish my needs, whereas the bucket brigades does.
I would veto it myself if I had time to back it up with a fully implemented
alternative.  Even so, there is no doubt in my mind that adding a dumb
filtering design to Apache at this point is far far worse than doing
nothing about filtering in 2.0.

At some point last week Ryan got frustrated and stopped listening
and we had a whole series of pointless "yes it does" "no it doesn't"
posts about niggling details that were quite meaningless when compared
to the overall design.  The design was wrong.  Then he thought about
more of the long-term issues and came back to try again.

Somewhere around Tuesday, Greg stopped listening and got into this
idiotic "prove my patch doesn't work" mode, and then we have another
pointless discussion of "yes it does" "no it doesn't" posts about niggling
details that were quite meaningless when compared to the overall design.
The design is still wrong.  Get over it.

If you guys spent half as much time commenting your code as you did
arguing about the edge cases, maybe we wouldn't have to spend so much
time trying to communicate?  Maybe it would help clarify the intention
behind some of the interface issues.  Like, for example, Greg's apparent
desire to stick to only what is needed by the ap_rwrite interface, which
I didn't see from reading the code.  I still don't care about that as
a design requirement, but at least now I understand a little more about
why the patch does what it does.

Here is my problem.  The early patches that were proposed were capable
of implementing 25% of the stream filter goals, with the ability to
be extended to 75%.  The latest ones implement maybe 70% with an
extensibility to 80%.  You seem to be suggesting that it is the first
number that matters in order to justify applying the patch.  My problem
is that I don't care about the first number -- I don't want a filter
interface in Apache that isn't capable of eventually handling 100%
of the problem space.  That's because I don't want to have to redesign
the interface after 2.0.0 goes out and everyone discovers that what
we have sucks.

To give you a bad analogy, our goal is to design a vehicle for a
California freeway.  That's what we mean by a commercial-grade server.
You don't get there by starting with a bicycle.  We can spend a lot
of time arguing about how one might retrofit a rocket pack on top
of the bicycle at some future date, but it doesn't change the underlying
nature of two thin wheels with wire spokes.

I can understand why we might want to start with a simple implementation
under the covers of an ADT.  What I don't understand is the theory that
we should start with an interface that we know isn't sufficient for the
task at hand and replace it later on.  We already know the right interface.
If you want a simple layer on top of that, no problem, but the most
efficient native interface must be the baseline.

Greg, I know this is more vague rambling on my part.  Let me make a
specific example.  Somewhere in your patch (as noted while catching
up on my e-mail today) is a filter function that is making a test
on filter->r->connection->aborted.  That is horribly wrong.

Consider the case where you have an active proxy implemented in the form
of a filter where you have one input filter chain reading the inbound
response and passing it downstream toward the client.  What r?  Which
connection?  Why the hell does the filter need to know anything about
the endpoints, let alone assume they are sockets?

The patch may work fine, but the design doesn't.  Data flow networks are
a very well-defined and understood software architecture.  They have a
single, very important constraint: no filter is allowed to know anything
about the nature of its upstream or downstream neighbors beyond what
is defined by the filter's own interface.  That constraint is what makes
data flow networks highly configurable and reusable.  Those are properties
that we want from our filters.

The second problem here is that this discussion contains too many
messages.  Both of you seem to have a need to respond to every message
on a point-by-point basis, and seem to get further annoyed when I don't
respond to every single point on those same messages.  What you don't seem
to be realizing is that you have generated so much text that the only people
who have enough time to both read the discussion and propose alternatives
are the two of you.  The rest of us just can't keep up.  I'd love to spend
some time flushing out the bucket brigades design, but instead I am spending
twelve hours a day reading the e-mail that gets stacked-up behind days
when I'm travelling, teaching classes, or otherwise doing what my real
job requires.  I don't want you to slow down, but for crissakes please
boil down the discussion to the meat and ignore the side-comments if
they are already covered by a prior message.

And I don't see any reason why we should hurry to get this in 2.0.
Not even my own personal favorite design is worth rushing into the
code base -- I'd rather make sure that the existing server works.

....Roy

Mime
View raw message