httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Buckets and Pails and Barrels, oh my.
Date Tue, 15 Aug 2000 14:08:25 GMT

In a message dated 00-08-15 08:31:28 EDT, Dean Gaudet writes...

> bucket is not nearly as overloaded as the half-dozen terms that
> non-creative engineers usually use, such as "list", "element", "buffer",
> "state", "record" ... and i'm not aware of any other use of the term
> bucket brigade.
>  -dean

There's a reason to use terms that already exist... especially
when you are going to ask other programmers to code to the API.
Most engineers ARE non-creative when it comes to lingusitics.
It's just the way it is.

'buckets' and 'bucket brigade' DO exist and qualify as 'prior art'... 
they were the basis for the VALIANT ( Voice Application Language Interface ) 
developed, trademarked, and copyrighted by Compass Computer Systems
in the early 1980's. It went on to become the basis for MANY
other voice response API's and is, I believe, currently owned
by Dialogic... the voice card giant.

I was there. I wrote half of VALIANT for Compass.

I am still researching whether the trademarked 'bucket' stuff
will cause ASF any problems once it releases an API that
uses the same names. If there are any legal implications I
will certainly let the group know. Your not-for-profit status 
probably protects you but if Dialogic really does own it and
they take exception it could end up in court anyway.

The only reason I piped up is because of personal experience
with the name choice . By the time a whole bunch of developers 
were done the 'simple' bucket_xxxx API idea got splintered
into all kinds of whacky shit like 'pails' and 'handles' and 
'lids' and 'barrels' ( Just like Manoj has already suggested ) and 
the brigade concept itself got out of hand with terms like 'put out
the fire' and 'pass buckets with one hand instead of two' and
all manner of ridculous crap.

There even ended up something like this...

if ( brigade_buckets_are_all_empty )

Besides that... we were continually amazed ( since the API
was published and licensed by many voice response companies )
at how difficult it was for developers to really get a handle ( pun
intended ) on the whole 'bucket' thing. We ended up having to
'translate' things anyway back into 'linked list' and ''buffer' and 
'FSP state' and all the other things you mentioned in order
for others to 'get it right'. Never underestimate the reluctance
of developers to learn any new concepts or terminology no
matter how simple the abstraction might seem.

That's all I wanted to say.

The 'bucket' and 'bucket_brigade' and 'pail' concept turned
out to be a good way to abstract the I/O design and get it 
coded but using the same abstraction for the published
API just turned into a nightmare ( for VALIANT, anyway ).

If no one has any problem with ap_bucket_xxxxxx and you
are ready for splinter code like ap_pail_xxxxx ( smaller buckets )
and ap_barrell_xxxx ( bigger buckets ) and ap_brigade_alarm()
and ap_brigade_fire_station() and god all what else to come out 
of it then go for it.

Whatever it takes to get it coded is probably best at this
point. Times' a wastin.

Kevin Kiley
CTO, Remote Communications, Inc. - Online Internet Content Compression Server.

View raw message