Re: FileSystem API: Avoiding Upload Forms And Temporary Downloads

On Mon, Nov 29, 2010 at 11:45 AM, Joran Greef <joran@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
>
>

Received on Wednesday, 1 December 2010 00:46:57 UTC