[Dancer-users] Feedback requested: streaming support

[sawyer x]

On Fri, Aug 19, 2011 at 10:53 AM, damien krotkine <dkrotkine at gmail.com>wrote:

>  > However, this wasn't enough for me. What if I don't want to stream one
> line
> > at a time. What if it's a binary and I want to stream it 512K at a time?
> > You're able to do that too. You can override the method that gets the
> > content's file handle and you can control what happens:
> >
> >     send_file(
> >         $binfile,
> >         streaming => 1,
> >         around_cb => sub {
> >             my $content_fh = shift;
> >             # now I can do whatever I want with it
> >         },
> >     );
>
> >
> Don't you need an additional argument, a ref on the sub to call, like
> in Moose 'around' keyword ? If not, then it's not an 'around', it's a
> wrapper. The $content_fh is pointing to the file you are trying to
> send, or the FH you should write to ? So instead of around_cb,
> something like data_send_callback, or a less crappy name actually :)
> Anyway do you see my point ? I assume this method gets called multiple
> time (once per chunk ?). If not, then it's not a callback. But I think
> it is :)
>

This troubled me for a bit. I wanted to be able to control every aspect of
it (that is, if a user wishes to), but around() should really be able to
control whether it gets run.

On one hand there's a question whether a user should be able to get full
control and on the other hand whether we can ease them so they don't have to
do know the gory details when they want to do something simpler. I've
decided to enable both.

- I removed "before_cb" and "after_cb", and strengthened the "around"
callback instead.
- I changed "around_cb" (now aptly named "around") do it gets the writer
(and the content filehandle, or complete content if you're using a scalar
ref to set exact content) and then you can read as much as you want, and
write as much as you want.
- I added "around_content" which gets the chunks of data each time it's read
(42K by default now, but configurable) and then a user can instead decide on
what to do with each chunk of content (whether to write it or not).

The "around_content" callback isn't as useful, because it just adds the
sysread() from the file handle inside Dancer instead of the user doing it.
If we find it completely useless, we could just remove it.

I finished everything else, only refactoring is left.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.backup-manager.org/pipermail/dancer-users/attachments/20110820/73678b17/attachment.htm>