On 19 August 2011 16:05, sawyer x <xsawyerx@gmail.com> wrote:
First, thanks to everyone for the quick feedback, I really appreciate it, :) Hopefully I'll be able to answer everyone.
1. Although I was originally against adding a callbacks => {} hashref key because I think it works against simplicity and the way Dancer feels for the user (and wrote in this email that I don't want to do it), after thinking about it some more, I've decided I'll change it as requested.
cool !
2. The reason this is in send_file() is because a. someone asked it for send_file specifically, and b. this is where it will be mostly used. People need to stream files. Refactoring this into another keyword (say, "streamed_response", or "streamed_content") will allow people to use this outside of send_file(), but it still remains very relevant inside send_file(). Yes, you can open the files yourself and take care of all of it, but if you'll need another layer of callback, and that's not very comfortable if all you want to do is to send a file streaming.
What about : stream_file() in addition to send_file() then ? Just to avoid adding more complexity to send_file() ? with redirection in the doc between the two ?
3. Buffering 42K (or even allowing the user to set it) is a good idea. I'll change that!
cool !
4. The around_cb will be changed to a more apt name.
cool !
5. I won't change any name to include "psgi" unless necessary, because a user shouldn't know what PSGI is.
Hmm well then, don't provide a callback where (quoting your words:) "you should understand how PSGI streaming works". If you do, be explicit that this is psgi related. I don't know, it seemed more "fair" to advertise it rather than hide it. Or, don't provide this method at all, or a wrapper that wouldn't require you to learn PSGI ?
It should be able to JFDI. In my opinion, the documentation is where I should note it uses proper PSGI streaming.
Maybe, why not, I'm not sure. Maybe ask for an other opinion ?
Anything I missed? Anything else?
And dams, I'm happy you're doing well. :)