[Bug 17262] send function should have async interface

https://www.w3.org/Bugs/Public/show_bug.cgi?id=17262

--- Comment #17 from Glenn Maynard <glenn@zewt.org> 2012-06-04 13:42:48 UTC ---

(In reply to comment #15)
> > This is a separate discussion, but actually it doesn't work at all ("Block all
> > writes until any already started reads finish").  The browser can't prevent
> > external applications from modifying files (at least short of using mandatory
> > locks, which are bad).
> 
> (notes; I'm not super familiar with FileSystem API)
> In the case of FileSystem API, it's sandbox-ed and separated from native file
> systems. We can assume it is not modified by external application. There is no
> difference from that OS assumes disks are not modified by VMM.

It's File API you want, not FileSystem API.  You can easily get a File for a
native user file, eg. using <input type=file>.

(FS-API is currently sandboxed, but there will likely be a native interface for
it eventually, but regardless it's only one possible way of getting File
objects.)

(In reply to comment #16)
> (In reply to comment #7)
> > * Neuter the blob such that any reads from it will fail
> > * Use a copy-on-write scheme such that any already existing Blob objects
> > maintain
> >   their values (this would likely be prohibitively expensive though).
> > * Block all writes until any already started reads finish
> > * Block all writes until all Blob references to the data go away.
> 
> Now, I feel the third one is the complete resolution.

You can't lock external files that can be modified by other non-browser apps
for the lifetime of the File object.

> The reason follows.
> 
> How can I use a Blob object which might become invalid suddenly?

By catching errors in the API you're using and handling them.  It'll always be
possible for reading a File object to fail; eg. the user might delete the file,
eject the DVD it's on, or an NFS error might occur.

The only way to prevent this is to copy the entire File out of native storage
when creating the File object, which is obviously not an option.

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Monday, 4 June 2012 13:43:12 UTC