On Mon, Nov 29, 2010 at 11:45 AM, Joran Greef <jo...@ronomon.com> wrote: > 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.
Yes, we've certainly talked about this as a logical next step for the API. We want to make sure the basic security/usability/quota issues with the current spec are dealt with before we expand to such use cases, but I think there's a lot of great stuff that could be built on this idea. For example, you might want to give flickr.com access to your photos directory. > 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. I don't see how Fitts' Law is relevant, but you raise an interesting point about drag-and-drop. When you drag a link out of an HTML document, that's usually a drag of a link, not a file. GMail implements attachment drag-out, but that's a copy, not a path. The FileSystem API will give you URIs that you'd build a page around just like any other; if you want different behavior than web URIs, we'd have to change something. I think you'd really want to implement this by overriding drag+drop behavior rather than changing the file API, but you may also need to give scripts access to the true underlying paths in order to make that work, and there are security issues with that. I'll keep it in mind; if you have a specific proposal for an API, please post it. > 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? This runs into the same issues as #2--local URIs would get treated differently than online URIs, we'd have to tell the applications the true locations of the files, and we'd lose any protection provided by the download manager. I'm not going to say that this is impossible, but it might require elevated privileges beyond those available to the average web page, and not everyone would want it. I'd like to see an extension do this and see how it went before I'd expect the web platform to allow it. > 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? I'm not sure what you're asking here. > 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 > >
