Mailing-List: contact apreq-dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Errors-To: <wrowe@rowe-clan.net>
Message-Id: <5.2.0.9.2.20030121185941.03ddf898@pop3.rowe-clan.net>
Date: Tue, 21 Jan 2003 19:01:24 -0600
To: Stas Bekman <stas@stason.org>
From: "William A. Rowe, Jr." <wrowe@rowe-clan.net>
Subject: Re: apreq-2 uploads as bucket brigades?
Cc: Joe Schaefer <joe+apache@sunstarsys.com>,
        apreq list <apreq-dev@httpd.apache.org>
In-Reply-To: <3E2DE4A8.3050406@stason.org>
References: <m3ptqtf5p5.fsf@mumonkan.sunstarsys.com>
 <047b01c2bfe4$795f4290$3f0aa8c0@fmenc001dev>
 <m3k7h1f0fc.fsf@mumonkan.sunstarsys.com>
 <87n0lws6wx.fsf@dedasys.com>
 <m3bs2acajx.fsf@mumonkan.sunstarsys.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 06:24 PM 1/21/2003, Stas Bekman wrote:
>Joe Schaefer wrote:
>
>>>FILE*'s can be passed to Tcl to create new file handles, and this is
>>>something that I feel is useful, because it gives you a really simple
>>>API for dealing with smaller files, even if it's not terribly
>>>efficient.
>>
>>It is useful, natural, and convenient.  I'd just like to avoid making it mandatory like we did with apreq-1.  XForms will present a new set of needs for our mfd parser, and the extra flexibility of brigades over
>>a vanilla FILE* pointer could be a really big winner there.
>
>Though it's not crossplatform. That's why apr is using apr_file_t and provides the method to extract the native implementation (FILE/HANDLE/...). I believe we should be using apr_file_t and not FILE*.

I would agree (as an apr hack.)

Can I suggest you also consider the benefit of a custom bucket type?
It might be possible to support the seek/read/write model against the
set-aside file while still supporting the brigade read.  This *could* be
a very happy compromise.

I can't go into it tonight (trying to get the Win9X users on 2.0.44
unbroken) but I'd be happy to share some more thoughts on this
later in the week.

Bill