Return-Path: Delivered-To: apmail-httpd-apreq-dev-archive@httpd.apache.org Received: (qmail 3740 invoked by uid 500); 19 Jan 2003 16:40:06 -0000 Mailing-List: contact apreq-dev-help@httpd.apache.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Delivered-To: mailing list apreq-dev@httpd.apache.org Received: (qmail 3665 invoked from network); 19 Jan 2003 16:40:05 -0000 To: apreq list Subject: apreq-2 uploads as bucket brigades? From: Joe Schaefer Date: 19 Jan 2003 11:46:30 -0500 Message-ID: Lines: 32 User-Agent: Gnus/5.0802 (Gnus v5.8.2) Emacs/20.5 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N I'd like to drop the req->upload linked list of temp files, and use bucket brigades in their place. I'd planning to use a common apreq_param_t struct which extends apreq_value_t like so: struct apreq_param_t { enum { ASCII, UTF_8, UTF_16, IS0_LATIN_1 } charset; char *language; apreq_table_t *info; /* mime headers */ apr_bucket_brigade *bb; /* represents file contents */ apreq_value_t v; }; The main advantage of this approach would be that we can use the full bucket api for managing the upload data. The brigade could use heap-allocated buckets for smaller uploads, and then switch over to mmapped or file buckets after a certain size. The bucket API makes this look pretty easy. The main disadvantage of this approach would be that we'd need to support the full bucket api for managing the upload. With actual files, seek(), dup(), link(), and buffered read() are natural operations. I think we'd have to provide a compatibility layer for some of these, perhaps using a meta-bucket at the front of the brigade? -- Joe Schaefer