The POST data from Gears is limited by the API to consist purely of a file slice. You have arbitrary control over headers, but there is not sufficient leeway in the API to compose a proper formenc multipart request - in particular, a POST body may not consist of any more file slices than one, nor can you add the required slice boundaries.
Basically this means it is impossible to emulate the wire traffic of a standard browser submitting a file upload set using the current Gears API... so it could as it stands not be used in conjunction with any existing backend. I agree with Colin that since this would substantially limit the appeal of the component to most of our users, that we should concentrate on improving the Flash uploader for now and wait for a refreshed release of Gears. Cheers, Boz. Jacob Farber wrote: > > So, just out of curiosity, what does the POST data from Gears look > like? How is it structured? > Jacob > > On Thu, Feb 12, 2009 at 10:15 AM, Colin Clark <[email protected]> wrote: > > > > 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. _______________________________________________________ fluid-work mailing list - [email protected] To unsubscribe, change settings or access archives, see http://fluidproject.org/mailman/listinfo/fluid-work
