httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: Isn't BUCKETS name a little lame? ( Was apr_sucks )
Date Mon, 14 Aug 2000 05:34:50 GMT

In a message dated 00-08-14 04:37:02 EDT, Greg Stein writes...

>  woo... "first post" goes to me. hehe... and after a night of drinking. oh,
>  what fun...

That sets the tone. Vodka or Bourbon?

If you or the Frisco kids have no problem actually using the data
abstraction of a 'bucket brigade' as the naming convention itself
for the filtering 'carrier wave' then more power to you.

Far be it from me to be the Henry Fonda in a room full of
Twelve Angry Men who have made up their minds. That
dog won't hunt.

I just thought some might think it hits a notch on the laugh-o-meter.

>  On Mon, Aug 14, 2000 at 04:14:48AM -0400, wrote:
>  >...
>  > I the only one who thinks that actually naming what will 
>  > probably be a very sophisticated filtering interface a 'bucket brigade'
>  > to be about the height of lameness itself?
>  Feh. You're not looking at this stuff right.
>  *) buckets and bucket-brigades are the data abstraction
>  *) filters are an orthogonal hunk o' code. they *use* the buckets in their
>     operation.

I know what the design looks like at the moment. Looks like
it didn't change much in Frisco. Looks like it's going to change
drastically again when Roy is done with it. That's fine. I wasn't
arguing the design. It's launched. It's going to take more than
liquor to go back now and it just needs to get committed and
hashed out.
>  >... stupid crap ...
>  > The whole 'bucket brigade' pass-the-stuff-along example is simply 
>  > what Roy used to try and explain what he was talking about but
>  > now it has ascended ( without due consideration ) to an actual naming
>  > convention and maybe it's time to think about whether it's really 
>  > appropriate before you get any deeper into it.
>  > 
>  > Keep 'bucket brigade' as a back-room way to explain the concept.
>  > Pick something ELSE for the actual function names.
>  Sorry. You lose.

Not keeping score myself. Just making suggestions.
>  We just had a big meeting about this stuff on Friday. *Everybody* seemed to
>  be quite happy with the term "bucket" and "bucket brigade". Those hold the
>  data.

Cool. Consent is good. Go for it. Glad to know the hatred for apr_
convention doesn't apply to 'bucket_xxxxxx'.

>  A separate beast, called "filters", happens to use the buckets and brigades
>  for passing data through a filter chain.

Of course. Early DOS TSR's used the same thing. I was there.

The VALIANT Voice response system even still has a trademark on the
'bucket' approach for I/O processing including the naming convention 
but don't worry... I think the company is defunct and no one is going 
to sue you. They got bought up by Dialogic or someone like that. I used 
to work for them and authored part of VALIANT. I can get you the trademark 
and patent numbers for the VALIANT system if you are at all worried about it. 
I wouldn't be. 
>  > Besides... I think you are going to discover by the time the dust
>  > clears that the 'bucket brigade' comparison is not going to 'hold
>  > water' ( pun intended ) under all filtering circumstances and when
>  > it is finished you will not only be stuck with a naming 
>  > convention that is a little lame but doesn't even really explain what
>  > is happening under all circumstances.
>  Ah, shut up. We had a dozen bright minds in a room. They all felt that the
>  bucket concept will carry us as far as we'd like to go. I'll place my bets
>  on that group over your FUD.

I'll take that at as a -1 for considering any name changes at all.

>  If you can name a *specific* problem, then I'll gladly listen.

Thought I did. Specific 'problem' was who does or doesn't think
that using 'bucket brigade' as an actual inline code naming 
convention hits a notch on the laugh-o-meter.

See above about Twelve Angry Men. The dog still won't hunt.

>  > Better to keep the API names generic up front.
>  > 
>  > Just my opinion, as well, of course... but tonight seems to be the 
>  > night for them.
>  Yup. My drunk, belligerent opinion, too.
>  All the smart brains that I respect like the buckets/brigades/filters
>  design. 

The design will probably work. I think you should look harder at zero-copy
re-entrance into the request processing engine for some of the simpler
filtering tasks but hey... who am I. Just a FUD pusher, right?

It's the NAMING conventions for the current filtering design I was 
wondering if anyone had a problem with. Guess not. OK. Fine.
Full speed ahead. Let's get something committed so the real
work can begin.

> That design is being implemented and will be checked in within a day
> or so.

I thought it already was? ( The Ryan stuff ).
Kevin Kiley
CTO, Remote Communications, Inc. - Online Internet Content Compression Server

View raw message