httpd-apreq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stas Bekman <>
Subject Re: Apache::Upload API
Date Fri, 18 Jun 2004 12:41:50 GMT
Joe Schaefer wrote:
> Joe Schaefer <> 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?

I need to do some work on error handling in APR::PerlIO, but otherwise I think 
it's pretty portable. At least as portable as its tests go. There are some 
issues with seek when perl and Apache have a mismatch on LFS, but otherwise it 
works fine.

Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker     mod_perl Guide --->

View raw message