On Sep 17, 2009, at 2:09 PM, Andrea Giammarchi wrote:
I wonder if massive uploads, like the ones you're coding for, really
aren't that common. I can imagine hard-coding that 3600 myself, and
thinking, "no way someone's going to be uploading a single file for
longer than an hour, or even close to it."
me too, also because for a silly connection problem you could even
re-start the upload from the scratch.
I do not think HTTP and a POST form "as is" is suitable for these
kind of tasks, I would rather think about a truly simple Desktop
software, Python for portability or AutoIT if it is only for
windows, able to split the file in chunks 2 Mb each and open a
conversation with the server in order to be able to resume the
upload if something goes wrong or if the user would like to.
With a desktop application you can send credentials and the SHA1 of
the file in order to create it's ghost image on the server. Every
chunk will be saved a part and when finished appended via file
pointers to the main one. To allow a resume you simply need to
communicate the current big file size / 2 Mb and you know which
chunk needs to be uploaded.
It is more simple to do than to explain, if you got this basic
example about how to proceed, but you need privileges over the file
in order to create a SHA1 and read only chunks via pointer, rather
than send everything in a shot.
Got php-apc patched and am testing now.
Good points about long downloads, but right now folks are using FTP
and they don't like it or understand it. In a biz environment,
connections are pretty stable, and usually fairly fast. This gives
them a familiar interface to upload. Anyway, this was the spec I was
given. Adding interruption recovery is a nice phase 2, upgrade.
I am just happy it is working now. The APC upload progress thing works
great (above mentioned limitations aside). Long haul, but pretty slick
in the end.
Thanks again for all y'alls help.
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php