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: filter design
Date Sat, 01 Jul 2000 05:45:25 GMT
In message <87k8f7cdkn.fsf@pobox.com>, Ben Hyde writes:
>
>In a case like this I pesonally would be reluctant to veto in 
>the absense of a significant commitement of time to dive into 
>the issue.

That's basically what I meant.

Voting on anything implies a commitment to work on the project.

For simple coding issues, a veto is fairly easy to define and the
solution is generally apparent from the reason for the veto.  Likewise,
if you simply think that a given piece of functionality should not be in
the server, that is pretty easy to describe and (obviously) wouldn't
require an alternative solution.  Those would be the anti-cruft feature
vetos that have done us very well over time.

In this case, however, we all agree that the functionality is worthwhile
having in the server.  We even agree (mostly) on whereabouts in the server
it should occur.  What we disagree on is the interface for interconnecting
and ordering filters, and quite possibly on the initial scope of what
filters should be able to handle.  The problem is we can't just apply one
patch and then take turns "fixing" the results, since there is nothing
iterative about the bucket brigades interface -- it is all or nothing.

I am a less tolerant of the "wait and see" approach to design than I used
to be.  I still don't like the module hook macros because they make the
run-time interface very hard to understand, but I have little chance of
fixing that at this stage without a version 3.0.  I have a sinking feeling
that adding content filters to the maze will make Apache completely
unstable in real-world environments, but a feeling isn't enough.

And, in reality, there is no need for me to veto anything here.  Greg
and Ryan will think about the issues whether or not there is a pending
veto, and I assume long after the code (in whatever form) is applied.
If there is a performance problem, it is much easier for me to demonstrate
it on a checked-out cvs copy of Apache (or in user complaints) than by
applying one of the proposed patches.  But I owe it to both of them to
explain what I think the issues are up front, rather than just blasting
away at it when we get closer to a gold release.

It's a pity that I can't convince people that the bucket brigades
interface is the only one that works, but it isn't all that surprising.
It took me a year of fooling around in Ada95 before I finally came up
with the right design for HTTP layering. *shrug*   And the only reason
I know it is the right design is because the things I want to do with it
require a 100% solution.  At no time whatsoever, under any circumstances,
can a filter be allowed to lose metadata by denying to others the source
of the content it is passing along.  Allow one ignorant filter in the mix
and you lose the ability for all sources on the server to be treated as
first-class resources.

But, if you start out with the supposition that 2.0 filters will be just
as ignorant as 1.3 content generators when it comes to HTTP, then Greg's
patch might work.  I'm not convinced that the memory allocation works,
or is even remotely efficient, but that is something we can fix later.
The thing I don't think we'll be able to fix later is all of the modules
once they start implementing ignorant filters.  CGI hell, all over again.

....Roy

Mime
View raw message