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