My users will upload files as large as 500M to my servers. This will of course take awhile and I think it's asking for trouble to let them submit and then just let the browser sit there and spin a currently-working-cursor without any other feedback. So, I use an IFRAME and some Ajax to submit the form and also poll to see how the submittion is coming along. Then I report this to user in the form of a progress-bar.
(Lots of examples of this, just search for "ajax upload progress" in Google.)
Anyway, by default in TBNL, as far as I can tell, the request doesn't hit my code until after the file has been uploaded. What I think I really need instead is to have access to the temporary filename created for the upload (so I can track its size) right before TBNL starts reading the file.
I've put this together locally by creating a hook in MAKE-TMP-FILE-NAME[1] which is simply called with the tmp-file-name created before returning. In my code I then use this filename to create data for the progress-bar.
My question is whether there's a better way to achieve this and/or whether or not you want a patch.
Thanks, Erik.
[1] I think a comment explaining that it's called from the RFC2388 code would've been really helpful. :-)
On Sun, 17 Sep 2006 14:45:02 -0400, "Erik Enge" erik.enge@gmail.com wrote:
My users will upload files as large as 500M to my servers. This will of course take awhile and I think it's asking for trouble to let them submit and then just let the browser sit there and spin a currently-working-cursor without any other feedback. So, I use an IFRAME and some Ajax to submit the form and also poll to see how the submittion is coming along. Then I report this to user in the form of a progress-bar.
(Lots of examples of this, just search for "ajax upload progress" in Google.)
See also here:
http://common-lisp.net/pipermail/tbnl-devel/2006-February/000559.html
Anyway, by default in TBNL, as far as I can tell, the request doesn't hit my code until after the file has been uploaded. What I think I really need instead is to have access to the temporary filename created for the upload (so I can track its size) right before TBNL starts reading the file.
I've put this together locally by creating a hook in MAKE-TMP-FILE-NAME[1] which is simply called with the tmp-file-name created before returning. In my code I then use this filename to create data for the progress-bar.
My question is whether there's a better way to achieve this and/or whether or not you want a patch.
I don't think there's a better way. But do you think that a hook for MAKE-TMP-FILE-NAME is the right solution? At that point you won't know for /which/ uploaded file you're called.
[1] I think a comment explaining that it's called from the RFC2388 code would've been really helpful. :-)
Hehe, yeah, even "Edit Callers" won't help you much in this case... :)
Seriously, this is a bit hacky anyway because the RFC2388 calls back into TBNL. I'd like to have a cleaner solution, but that'd probably imply that TBNL implements its own RFC2388 parsing.
I'd like to provide something in TBNL to enable things like upload progress bars, but I'm still looking for a solution that looks clean and unobtrusive to me.
Cheers, Edi.
On 9/17/06, Edi Weitz edi@agharta.de wrote:
See also here:
http://common-lisp.net/pipermail/tbnl-devel/2006-February/000559.html
Thanks!
I don't think there's a better way. But do you think that a hook for MAKE-TMP-FILE-NAME is the right solution?
Conceptually the hook should probably be "after we have the filename, before we start reading the file". Good luck finding a good name! ;-) (I named mine *pre-file-upload-hook* which I'm not satisfied with but I can't think of anything better right now.)
Whether that's in MAKE-TMP-FILE-NAME or not doesn't really matter to me. The reason I picked it was simply that I didn't want to change RFC2388, because as you say, the way it works now by calling back into TBNL is hackish enough already. :-)
At that point you won't know for /which/ uploaded file you're called.
Actually I do know. At that time *REQUEST* is bound and I store a session-key in a cookie that's passed in. So what I do in my hook is retrieve the user doing the upload, via the cookie, then store the temporary filename in my database as part of the user's session. This way my Ajax calls won't have to pass around a filename and there's no way for the user or browser to see my filesystem layout and/or change the filename that's checked in the progress bar.
Seriously, this is a bit hacky anyway because the RFC2388 calls back into TBNL. I'd like to have a cleaner solution, but that'd probably imply that TBNL implements its own RFC2388 parsing.
Yeah, not sure what the best approach is yet. To be honest, I haven't looked much at the RFC2388 library.
I'd like to provide something in TBNL to enable things like upload progress bars, but I'm still looking for a solution that looks clean and unobtrusive to me.
The simplest way I can think of is with a hook right when we have the filename but before we start writing to that file. It's the one I'll be using for now but if I think of something better down the line I'll be sure to suggest it here.
The older thread you linked suggested modifying RFC2388 to write a status file but this is an extreme specialization of the RFC2388 library, in my opinion.
Thanks, Erik.
On 9/17/06, Erik Enge erik.enge@gmail.com wrote:
Actually I do know. At that time *REQUEST* is bound
Hm, there are gremlins in my code. *request* can't be bound at that point because make-tmp-file-name is called from rfc2388:parse-mime which is called from parse-rfc2388-form-data which is called in initialize-instance :after on request.
I guess I'll patch TBNL locally to write the raw-post-data after initialize-instance is done.
Erik.
On Sun, 17 Sep 2006 19:33:51 -0400, "Erik Enge" erik.enge@gmail.com wrote:
The simplest way I can think of is with a hook right when we have the filename but before we start writing to that file.
I've added that now - see doc entry for *FILE-UPLOAD-HOOK*. Please try if it works for you. I think that's the best I can do ATM without modifying the RFC2388 code.
Cheers, Edi.
On 9/30/06, Edi Weitz edi@agharta.de wrote:
I've added that now - see doc entry for *FILE-UPLOAD-HOOK*. Please try if it works for you. I think that's the best I can do ATM without modifying the RFC2388 code.
Great, this works as expected. Thanks!
Erik.
-
Edi Weitz -
Erik Enge -
Stefan Scholl