httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: Thoughts on filter-chain composition
Date Tue, 12 Sep 2000 07:28:46 GMT

In a message dated 00-09-12 04:51:22 EDT, Greg Stein writes...

> When the messages are four pages long, I tune out around the second page. I
> would guess most people do the same thing (certainly sounds like Tony and I
> are similar here).

I am the CTO of a virtual company with people all over the world. I know what
a pain in the ass it is trying to develop a piece of software with email and
code fragments alone. Sometimes the reader's digest version just leads
to more confusion. I, myself, would rather read the long versions than
have the thread go on and on with it coming out in dribs and drabs.

Witness the whole Greg (you) / Ryan exchange over the filtering concepts. 
It simply wasn't something that could be presented in 10 line emails. It just 
up leading to 20 more messages saying 'Well what I really meant to say 

Even now the lack of understanding regarding filtering has more to do with
the fact that there were simply hundreds of individual emails flying around...
not that any one of them was hard to understand. It was the sheer volume
of messages that caused the 'skip out' on that thread.

>  If you want to make certain points, then do it concisely. You stand a much
>  higher chance of actually making that point. Bury it in your standard 
>  paragraph treatise, and it just won't happen.
>  Not speaking for everyone, but people just don't want to spend the time to
>  wade through that much stuff.

Your point is well taken... and you are correct. You don't speak for everyone.
I wish you guys would say MORE than you do. I read fast. Others do too.
>  Note that we also ask for teeny patches for much the same reason: once
>  things get past a certain size, the system breaks down and people won't 
>  the stuff. 

I know. I think that's a shame. Don't know what the answer is. It's a heck
of a way to try and advance a piece of software... one 5 line patch at a
time because that's all the attention spans will bear.

Speaking of which... I submitted a pretty important patch just a few
days ago. Yea... it was long... but that's what it took to do the job right.

Has anyone looked at it? I guess not. Too bad. It works AOK.

> Since our goal here *is* to have people read the patches/commits,
> we have an unwritten(?) policy to keep them short, single-minded, and
> concise as possible.

When that unwritten policy means that good feature additions just aren't
making into the product IMHO it's time to review the unwritten policy.

The real goal is the advancement of the technology. The development
habits should change as needed to make sure things aren't falling 
through the cracks. Again, just MHO.
I still think you guys need more than 1 list for primary development
discussions. It always pisses someone off when people are clogging
the mainline trying to hash out something 'they' aren't interested in. 
There's a lot going on in Apache. A lot more than 1 post list can handle.

Send the hash sessions over to a 'semi-private room'. Summaries and 
results (only) post back to new-httpd.

Why don't you guys have CHAT rooms or something? Get discussions
going with volunteer moderators... you know... that kinda stuff. It would 

>  p.s. that said: there is nothing in the current design to prevent dynamic
>  addition/removal/rearrangement of filters. *if* you know what you're doing
>  and you do it before content begins to flow past you in the filter stack.

That's good. It just sounded a message or two back like that was going
to be PREVENTED. That would be badness. ( See Ken Coar posting ).

Kevin Kiley
CTO, Remote Communications, Inc.
http://www.Remote - Online Internet Content Compression Server.

View raw message