Stas Bekman <[EMAIL PROTECTED]> writes:
[...]
Moving $b->remove to the end makes the code horribly kludgy. It's better to change the idiom to step through the buckets instead of removing them. Adjusting John's sample code:
my $bb = $r->upload('file')->bb(); open(OUT,">/tmp/test_file"); for (my $b = $bb->first; $b; $b = $bb->next($b)) { $b->read(my $data); print OUT $data; } close OUT;
Joe, does this idiom work fine with file buckets?
In principle this is fine, but there is a practical issue to consider: this idiom has the effect of reading the file bucket back into memory until there are no more file buckets left in the brigade. If the upload was large enough to warrant a spool file to begin with, slurping it all back into memory as chunks is not a good idea.
What I'm going to recommend in the Apache::Upload docs is ask people to use the TIEHANDLE api for io() instead:
my $io = $req->upload("foo")->io; print while read $io, $_, 8000; # read() will manage the buckets for you
Do you mean the difference is in being able to request chunks of limited size (8k?). Otherwise the two are equivalent.
May be we need to change the $b->read method to support an optional length argument, like apr_bucket_read does. In which case it'll be possible to do the same, w/o the TIEHANDLE interface. Though the user will need to manage the under/over-reads, which is a hassle.
In addition TIEHANDLE adds an overhead, have you tried running a benchmark with these two chunks of code?
We need to write a test for this case, but at the moment we have no API to create file buckets. I guess we could test that in an output filter and have a response handler call sendfile, which should create a bucket of file type.
BTW, John you could also do:
my $bb = $r->upload('file')->bb(); my $len = $bb->flatten(my $data); print OUT $data;
though it's probably less memory-usage effective.
Hah, aren't *you* the guy that asked for $upload->slurp(my $data)?
Now you're recommending $upload->bb->flatten, which does exactly
the same thing (deja vu?).
So, can we go back and get rid of slurp() now? :-)
While it's quite possible, I can't find myself suggesting that in the archives:
http://marc.theaimsgroup.com/?l=apreq-dev&w=2&r=1&s=slurp&q=b
Can you find the thread where it was discussed?
In any case, I think $r->upload->slurp(my $data) is a goodness as it doesn't require the user to even be aware of the internal representation. But either of the two slurp techniques shouldn't be the recommended practice, as it will bloat memory. (Unless a user is going to read the whole thing into memory anyway).
-- __________________________________________________________________ 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
-- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
