Stas Bekman <[EMAIL PROTECTED]> writes:
[...]
You need the filehandle only if you use the temp file. In which case bbs are irrelevant. If you use slurp then there is are no filehandles. I think these are orthogonal.
Agreed- my earlier +1 was for both adding a slurp() method and marking the output as tainted.
Understood.
So since we are designing a new interface. Would it make sense to have slurp() accept an optional argument limiting the size of the data it's going to slurp? I mean the MAX_POST_DATA (or whatever it is) limit is all good, but since for big data we mainly use temp files MAX_POST_DATA, we may want to say
upload->slurp(2**14) or die "the input is too big";
actually, I'm having another idea on slurp. Since it smells too read()-like. One could have an APREQ::PerlIO layer and having upload return that filehandle opened through that layer (like APR::PerlIO or Apache::PerlIO do). Now you could transparently do temp files or inmemory uploads, giving the user the good old read() API. You can even support seek/tell to make things fancier. Of course this will require perl 5.8 compiled with perlio.
If you have that in place, you need no slurp. You do 'local $/ + read' and you get slurp. Or may be it's too much work when implementing slurp should be a few lines of C code ;)
__________________________________________________________________ Stas Bekman JAm_pH ------> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
-- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
