Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Message-ID: <20001209184510.11335.qmail@web3202.mail.yahoo.com>
Date: Sat, 9 Dec 2000 10:45:10 -0800 (PST)
From: Cliff Woolley <cliffwoolley@yahoo.com>
Reply-To: cliffwoolley@yahoo.com
Subject: Re: cvs commit: apr-util STATUS
To: rbb@covalent.net, dev@apr.apache.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

--- rbb@covalent.net wrote:
> No, ap_bucket_copy_any should not be named ap_brigade_copy.  The whole
> idea behind a copy_brigade function is inherently flawed.

I had sort of thought the same thing myself, but I figured I might as well ask
anyway.

> In order to be able to use the copy_any function, we would
> need to read the data, to find the limits of what we want to copy, and
> then call the copy_any function.  Of course at this point we know that we
> have a bucket that can be copied, so we are better off just using the copy
> function directly.

That's a good point.  I'm really not particularly attached to copy_any()... I'd be
+0.5 for nixing it.  I only slapped it in there in the first place because by my 4am
mentality it seemed to fit in with split_any(), which is now having its purpose in
life changed anyway.

> Please provide an example of where these functions are useful, because I
> don't see it.  I would like to just remove them unless we are actually
> going to use them.  If we aren't going to use them, then we are just
> making the API more complex for no reason at all.

I honestly can't think of a good reason to have copy_any or brigade_copy, now that I
stop to think about it.  Any case that would have used it would have other problems
to deal with.

On the other hand, brigade_split_offset does seem useful to me.  Consider a filter
that does some sort of compression or encoding that requires the data to be split
into blocks of a predetermined length, regardless of what's actually in those
blocks. This doesn't apply to mod_include, as you've pointed out, because it
actually has to examine the data to figure out where to split.  But that will not
always be the case.

Anyway, at this point, I'd say we should go ahead and change split_any() to
ap_brigade_split_offset(), moving it in to ap_buckets.c so it can hang out with
ap_brigade_split().  Then we should just ditch copy_any(), deleting
ap_buckets_util.c.

Does that sound reasonable?

--Cliff

__________________________________________________
Do You Yahoo!?
Yahoo! Shopping - Thousands of Stores. Millions of Products.
http://shopping.yahoo.com/