Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Date: Sun, 26 Aug 2001 21:26:06 -0700
From: "Roy T. Fielding" <fielding@ebuilt.com>
To: "William A. Rowe, Jr." <wrowe@rowe-clan.net>
Cc: Greg Stein <gstein@lyra.org>, dev@apr.apache.org
Subject: Re: apr_bucket_simple_split
Message-ID: <20010826212606.A1690@waka.ebuilt.net>
Mail-Followup-To: "Roy T. Fielding" <fielding@ebuilt.com>,
	"William A. Rowe, Jr." <wrowe@rowe-clan.net>,
	Greg Stein <gstein@lyra.org>, dev@apr.apache.org
References: <Pine.GSO.4.32.0108251706340.17557-100000@cobra.cs.Virginia.EDU>
 <20010826020022.E2111@lyra.org> <076701c12e4c$78411d50$95c0b0d0@roweclan.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <076701c12e4c$78411d50$95c0b0d0@roweclan.net>
User-Agent: Mutt/1.3.20i

> No.  There really aren't many sendfile implementations that allow you to
> transmit more than an apr_size_t, if you start digging the man pages.
> Afraid this was a concensus decision make while you were on holiday.

Ummm, no it wasn't.  You mentioned it on the mailing list and both Bill
and I said it wasn't appropriate for a bucket to be limited to apr_size_t
bytes, and then you committed a huge change to make it all consistent.
It was better than the previous mishmash, so I saw no reason to veto it,
but you can't call that a concensus (not even a lazy one).

> Since buckets are atomic units,
> they need to correspond to an atomic sendfile/read/whatever.

No they aren't.  They are buckets of data -- nothing to do with atomicity.

> The -brigade- is effectively unlimited.  But individual buckets represent one
> 'apr_size_t' worth of data.  The code became immensely less complex, and
> since 
> nobody else worked on buckets type/data safety, I fixed this to be consistent
> through the server.

Consistency is good.

> > First off, that the point should be an apr_off_t.
> 
> -1, and that's a veto, until you (or anyone else) writes a proper patch to
> handle all apr-util and http buckets paying attention to the size arguments,
> throughout, and mapping between size and len and off.  Until that happens,
> this is a size_t.

Great, so now the implementation works but the interface is wrong.  Guess
which is harder to fix after a major release?  I think its fine that the
code has been cleaned up, but the fact is that this interface will change
back to being apr_off_t at some point.  And if you don't like that, then
sorry -- I'd rather veto your commit and go back to the inconsistent state
of warnings on win32 than allow an interface to persist that is just plain
wrong.

....Roy