httpd-apreq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Schaefer <joe+gm...@sunstarsys.com>
Subject Re: Apache::Upload API
Date Thu, 17 Jun 2004 17:57:42 GMT
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


Mime
View raw message