Updates on the HTTP file upload front
Right now I'm happy. Why's that? Because I have a neat Google Gears-based file uploader that uses hardly any code and no special server requirements or code requirements. It is *almost* everything I've been trying to accomplish with my behind-the-scenes type efforts to scare up some development... and this was accomplished so quickly it was scary.
Big props to Raghava @ work. He did the legwork of putting together the base code that makes Gears work properly and enough for me to play around with. Between the two of us I think we'll be able to conquer the rest of it.
Okay, so what exactly was I hoping for?
- No special server requirements - PHP is all that is needed, data comes via POST
- Not one single huge request - yes, the files are split up in memory at runtime as needed into configurable-sized chunks
- Large file support - yes, as large as any component allows, at least
- Multiple file support - yes, uploads happen in a serial fashion
- Friendly file selection UI - yes, it uses the OS's file browser like a normal file upload
- Transparent HTTP/HTTPS support - have not tested it on an SSL-enabled box, but I see no reason why it wouldn't work (it's basically like an XHR request)
- Retransmission on failure - no, I believe the Gears developers need to implement additional settings/capabilities into the "httprequest" class - this is the biggest gap
- Pause/resume support - no, I don't think this is supported quite yet in our implementation
- Persistence - being able to resume later on after power outage, browser closing, etc. - no, but possibly an option if integrated into the Gears local database
- Parallel processing (not required, might be neat) - possibly with a Gears worker pool, but not really a big enough deal to bother
Right now what we've got pretty much meets most of the needs. The biggest gap here is making sure it attempts re-transmission. Without that, this is still very cool, but that will be one of the major benefits this exercise could offer.