--- "William A. Rowe, Jr." <[EMAIL PROTECTED]> wrote: > Correction... it's all I agreed with. Built in bucket accessors should only > do > what that bucket can natively do in an atomic fashion. Wider functions can > do the > overload of handling broader cross-bucket features and accept a bucket arg, as > we do throughout the apr_bucket_util functions.
Okay, fair enough. Sorry if my memory of people's positions was slightly off after a month's time. Ryan, Bill, I apologize. Since ap_bucket_split_any() is what we agree on, then let's move on and figure out what the best approach is to improving it to handle sockets and pipes better. It really is too bad that the read() function ignores the len parameter. If it didn't, then split_any() could just tell it how much to read, and this wouldn't be as much of an issue. Alternately, split_any() could just keep track of how much was read and loop through an arbitrary number of reads, incrementing until the totals matched. That's the least intrusive approach. I'll implement it if people agree. Thoughts? --Cliff __________________________________________________ Do You Yahoo!? Yahoo! Shopping - Thousands of Stores. Millions of Products. http://shopping.yahoo.com/
