Uploader, Gears, and multipart POSTs

Colin Clark colin.clark at utoronto.ca
Thu Feb 12 15:15:04 UTC 2009


Hey everyone,

As you know, I've been playing around with the latest version of  
Google Gears, which provides support for multi-file uploads. I was  
hoping to use it in as an alternative to the Flash back end in the  
Uploader, since we've somewhat disappointed by the accessibility of  
Flash 10.

Gears provides a pretty good API for uploads. Compared with the code  
required to bootstrap SWFUpload, I was able to implement a preliminary  
version of the code with significantly fewer lines of code. Gears also  
provides some intriguing forward-looking features, such as the ability  
to do offline uploading and to pause a file and resume it much later on.

I hit a snag with Gears the other day, though. Anyone who's built a  
standard HTTP file upload will be familiar with how they work. In  
short, the client makes a POST request to the web server. The request  
needs to have a content type of "multipart/form-data" so that the  
server knows how to correctly process it.

Adobe, who aren't famous for following Web standards, did the right  
thing in Flash. They compose a valid multipart POST request when  
sending files to the server. Thus you don't need to write any special  
server-side code to handle Flash-based multi-file uploads (with a few  
caveats, perhaps).

On the other hand, Gears doesn't allow you to make multipart POSTs. As  
a result, users of the Uploader component would be required to write a  
separate, Gears-specific handler on the server. Given that we've  
always imagined that Gears support would be a "progressive  
enhancement" on top of our support for Flash and plain old HTTP  
uploads, I'm not sure this is going to make our users very happy.

For now, I'm figuring we're best to shelf Gears support for the  
Uploader and see if we can implement a couple of hacks to make Flash  
10 more keyboard-friendly. From what I've seen, Google is aware of the  
multipart POST issue in Gears and has a fix coming eventually. At that  
point, we can pick this work up and release it in a future version of  
Infusion.

Thoughts?

Colin

---
Colin Clark
Technical Lead, Fluid Project
Adaptive Technology Resource Centre, University of Toronto
http://fluidproject.org




More information about the fluid-work mailing list