Re: cvs commit: apr-util STATUS

2001-12-08 Thread Aaron Bannert
On Sat, Dec 08, 2001 at 12:43:54AM -, [EMAIL PROTECTED] wrote: > jerenkrantz01/12/07 16:43:54 > > Modified:.STATUS > Log: > Grumble, grumble. One problem fixed, another created. ... > -* Try doing --with-dbm=db2 when you have db3 available. No go. > - Justi

Re: cvs commit: apr-util STATUS

2001-04-10 Thread rbb
> +* add misc/version.c and related machinery once the pattern is > + layed out in APR. I know we have discussed the location before, but misc/ is a horrible name, and I had a few people point it out to me at ApacheCon. So, although it is the best I have, I would like to ask people

Re: cvs commit: apr-util STATUS

2001-01-13 Thread William A. Rowe, Jr.
> wrowe 01/01/12 20:23:31 > > Modified:.STATUS > Log: > Vote on some things so we get this out the door! > >RELEASE SHOWSTOPPERS: > > +* This vote ends on Wednesday! > + Source code layout needs to be decided for apr and apr-util. There > +

Re: brigade/bucket splitting (was: Re: cvs commit: apr-util STATUS)x

2000-12-12 Thread Cliff Woolley
--- Greg Stein <[EMAIL PROTECTED]> wrote: > The reason that I asked for a bucket return value was so that we could split > the brigade at point P3/4, and get a pointer to B4 back (the start of the > copy). We split at point P6/7 and get P7 back (the bucket after the last to > copy). Oooohhh y

brigade/bucket splitting (was: Re: cvs commit: apr-util STATUS)x

2000-12-11 Thread Greg Stein
On Sat, Dec 09, 2000 at 01:14:57PM -0800, [EMAIL PROTECTED] wrote: >... > I'll buy this. I can see this being somewhat useful. Part of me thinks > this should be implemented as a brigade_seek function. The calling code > would then be responsible for calling ap_bucket_split and > ap_brigade_spli

RE: cvs commit: apr-util STATUS

2000-12-09 Thread rbb
> --- [EMAIL PROTECTED] wrote: > > I'll buy this. I can see this being somewhat useful. Part of me thinks > > this should be implemented as a brigade_seek function. The calling code > > would then be responsible for calling ap_bucket_split and > > ap_brigade_split, but I am not sure if I agree w

RE: cvs commit: apr-util STATUS

2000-12-09 Thread Cliff Woolley
--- [EMAIL PROTECTED] wrote: > I'll buy this. I can see this being somewhat useful. Part of me thinks > this should be implemented as a brigade_seek function. The calling code > would then be responsible for calling ap_bucket_split and > ap_brigade_split, but I am not sure if I agree with that

RE: cvs commit: apr-util STATUS

2000-12-09 Thread rbb
> > Okay, so that wasn't the best example, since a compression or encoding > > filter would > > have to read the data to compress or encode it anyway. Bah. What I was > > really > > trying to get at was something more like the byterange filter. Why is it > > that an > > ap_brigade_split_offs

RE: cvs commit: apr-util STATUS

2000-12-09 Thread rbb
> > This is now apr-util, so it should be something generally useful outside of > > the > > server for other bucket brigade apps. > > +1. > > I'm going to go ahead with a patch to do as I proposed before (change from > split_any > to brigade_split and delete copy_any). We can debate it furthe

RE: cvs commit: apr-util STATUS

2000-12-09 Thread Cliff Woolley
--- "William A. Rowe, Jr." <[EMAIL PROTECTED]> wrote: > How about a better example, a binary result filter from a known filetype. > E.g. we > have this .gif image that we know from the header we will play with a certain > range of bytes in the body, so ap_brigate_split_offset forward to that par

RE: cvs commit: apr-util STATUS

2000-12-09 Thread William A. Rowe, Jr.
> From: Cliff Woolley [mailto:[EMAIL PROTECTED] > Sent: Saturday, December 09, 2000 12:52 PM > > > 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

Re: cvs commit: apr-util STATUS

2000-12-09 Thread Cliff Woolley
> 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. Okay, so that wasn't the best exa

Re: cvs commit: apr-util STATUS

2000-12-09 Thread Cliff Woolley
--- [EMAIL PROTECTED] 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 functi

Re: cvs commit: apr-util STATUS

2000-12-09 Thread rbb
> No sweat... I'll do this this afternoon. One question, though... should > ap_bucket_copy_any() also change to ap_brigade_copy()? The same issues apply > to it > as apply to _split_any(). No, ap_bucket_copy_any should not be named ap_brigade_copy. The whole idea behind a copy_brigade functio

Re: cvs commit: apr-util STATUS

2000-12-09 Thread Cliff Woolley
--- [EMAIL PROTECTED] wrote: > +* turn ap_bucket_split_any() into ap_brigade_split(). > + Message-ID: ??? > + Status: Greg +1 > + Note: awaiting code from Cliff Wooley for this No sweat... I'll do this this afternoon. One question, though... should ap_bucket_copy_any()