On Fri, Aug 19, 2011 at 10:53 AM, damien krotkine <dkrotkine@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.