Mailing-List: contact apreq-dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Mail-Followup-To: apreq-dev@httpd.apache.org
To: apreq-dev@httpd.apache.org
From: Joe Schaefer <joe+gmane@sunstarsys.com>
Subject: Re: Apache::Upload API
Date: 17 Jun 2004 13:57:42 -0400
Lines: 35
Message-ID: <87r7sexe21.fsf@gemini.sunstarsys.com>
References: <CBtJ5f4s4sXhUGvzhDXGpqAhlyQP7E7axzMBITwo1mC@akmail>
 <87659qz4gv.fsf@gemini.sunstarsys.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Mail-Copies-To: never
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2
Sender: news <news@sea.gmane.org>

Joe Schaefer <joe+gmane@sunstarsys.com> writes:

[...]

> > When I last looked at the apreq2 source a few months ago, I was under
> > the impression that the code stores small uploads in memory, and only
> > writes them into spool files from a certain size upwards. Which might be
> > the reason why the filename() and fh() methods are not available
> > anymore. But it seemed to me that to provide link(), the code does
> > create files for smaller uploads when required. Couldn't this also be
> > done to provide filename() and fh() again?
> 
> I'd *really* prefer to stay out of the IO game in Apache::Request
> (moving filehandles between apache and perl is a gigantic mess).
> I'd rather argue for some sort of brigade-as-filehandle mechanism
> in APR::Brigade, precisely for the backwards-compatibility +
> interoperability reasons above.

Sorry, let me try to sound a little more positive.  To take your points
in order:

  1) Yes, you are correct that apreq2 does not do IO on smallish
     uploads, but link() will induce a write-to-file.  What this
     code could easily be reused for is to transform the bucket brigade
     to an apr_file_t pointer on demand.  But then how should we expose
     that pointer back to perl- APR::PerlIO?  How portable is APR::PerlIO?
     Would we need the old dup() cruft from apreq1? Stas, Geoff?

  2) filename() just needs be written (remember it's the client-reported
     filename buried in the Content-Disposition header).  It's easy to 
     implement now, just nobody has bothered to do it yet.  That 
     definitely that will be resolved before 2.04-dev.

-- 
Joe Schaefer