W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2010

FileSystem API: Avoiding Upload Forms And Temporary Downloads

From: Joran Greef <joran@ronomon.com>
Date: Mon, 29 Nov 2010 21:45:15 +0200
Message-Id: <5A35598E-241E-402B-BD5D-42E825B8D965@ronomon.com>
To: public-webapps@w3.org
I have some questions regarding the FileSystem API: 

1. It would be great to be able to let the user choose where they want their sandboxed directory located for the web app, i.e. on the desktop for quick access. That way they can drag files directly to the directory, which could be used as a dropbox for synching to a server. Would this be possible (or at least a mechanism to link to the directory wherever the browser may choose to place it)? Otherwise, apps like Dropbox would not be possible in a browser.

2. It seems that dragging a file out of a web app is currently copy-on-write? So you drag a file out the web app into Excel but subsequent changes in Excel would be lost to the web app (it seems like it's already possible for the web app to poll the sandboxed directory for file changes)? If so, it means that the FileSystem API would force the following work flow: the user saves a temp file somewhere (probably on the desktop) then re-uploads using a web form, and then minimizes the browser and deletes the temp file, and then maximizes the browser again? That would be a bad case of Fitts' Law and quickly become a show-stopper if the user needs to frequently edit files using native applications.

3. It must be possible to link to files within the sandboxed directory and have them open in the default native application. I can understand that .exe's need to be neutered, but content files such as .doc and .xls must have a method for opening in the default application. Would this be possible? Otherwise the only solution would be to trigger the Download window, creating a temp file in the Downloads folder for a file that already exists on the filesystem?

4. In my mind, the FileSystem Api has a shot at improving user experience by helping to avoid file upload forms, and temp file downloads. I'm not sure these goals are possible with the current spec?

These use-cases may prove to be vital building blocks for the next wave of networked applications and it would be great to see them in the new FileSystem API.

Regards

Joran Greef
Received on Monday, 29 November 2010 22:36:44 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:42 GMT