On 26/11/2013 12:54 PM, John Napiorkowski wrote:
We should probably document what it means by $c->response->body can
accept a file handle. Like plack specifies the interface it must deal
with. Anyone up to that?
Something along these lines maybe?
Catalyst can accept a file handle type of object as the response body in
the sense that the handle reasonably has a "read" method that will
return content. In such a case and where no content length has been
already set in the response headers catalyst will make a reasonable
attempt to determine the size of the file. Depending on the
implementation of your file handle object setting the content length may
fail. If it is at all possible for you to determine the content length
of your file handle, it is recomended that you set the content length in
the response headers yourself, which will be respected and sent by
catalyst in the response.
This FH in body thing is something I've been thinking about a lot
lately, in regards to when Catalyst is running under an event loop for
example, should Catalyst stream the Filehandle a non blocking manner.
But it would be great to document this. Also, I am thinking setting
the default size when its missing could really belong to middleware.
Plack has some default middleware that does this:
https://metacpan.org/source/MIYAGAWA/Plack-1.0030/lib/Plack/Middleware/ContentLength.pm
Which interestingly does not take a too different approach to what the
Catalyst code is attempting. Also noting that in a case such as Bill
presented it too would fail, which is only to be expected.
Noting such IO magic modules like IO::Uncompress::* and IO::Scalar etc
and speaking of cat skinning, another approach could be subclassing
these modues and overloading the file test operators to do something
sane when used, and thus return a "correct" response when the -s test is
used. Or try and convince said authors to have these classes do this
natively.
the means it works looks like this
https://metacpan.org/source/MIYAGAWA/Plack-1.0030/lib/Plack/Util.pm#L68
There's a few things in Catalyst.pm that could profitable just use
Plack::Middleware counterparts.
just a thought.
johnnap
On Thursday, November 21, 2013 9:20 AM, neil.lunn <[email protected]>
wrote:
On 22/11/2013 12:33 AM, Bill Moseley wrote:
On Wed, Nov 20, 2013 at 11:32 PM, neil.lunn <[email protected]
<mailto:[email protected]>> wrote:
This approach may work for you is the compressed data is actually
in a scalar and not too large. And not too small. YMMV.
my $z = read_file "product.json.gz";
my $io = IO::Scalar->new( \$z );
$io->seek( -4, 2 );
$io->read( my $buf, 4);
my $uncompressed_size = unpack( 'V', $buf );
This indeed does work in my tests. Thanks for all the help, Neil. I
really appreciate the time you spent on this.
No prob. Part of my thing on list reponses is that there is a seed for
others to learn from what was discussed.
I do wonder if there is a sane way to test for an in memory file
handle and give a more appropriate warning, but that is for further
discussion.
--
Bill Moseley
[email protected] <mailto:[email protected]>
_______________________________________________ List:
[email protected] <mailto:[email protected]>
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive:
http://www.mail-archive.com/[email protected]/ Dev site:
http://dev.catalyst.perl.org/
------------------------------------------------------------------------
<http://www.avast.com/>
This email is free from viruses and malware because avast! Antivirus
<http://www.avast.com/> protection is active.
_______________________________________________
List: [email protected] <mailto:[email protected]>
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive:
http://www.mail-archive.com/[email protected]/
Dev site: http://dev.catalyst.perl.org/
_______________________________________________
List: [email protected]
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/[email protected]/
Dev site: http://dev.catalyst.perl.org/
---
This email is free from viruses and malware because avast! Antivirus protection
is active.
http://www.avast.com
_______________________________________________
List: [email protected]
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/[email protected]/
Dev site: http://dev.catalyst.perl.org/
