[Bug 17262] send function should have async interface

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

--- Comment #21 from Glenn Maynard <glenn@zewt.org> 2012-06-05 16:06:46 UTC ---
On the original point of this bug: It sounds like your basic issue was that you
read send(Blob) as though it can be synchronous.  Maybe it should be more
explicit that it's always asynchronous.

(In reply to comment #20)
> In our case, scripts have no chance to catch read errors. Because sending
> operation is just queued and actual operations are processed by internal
> implementation. All we can do here is to send close frame with status code 1011
> and to close the connection. 
> I think we never want to close the connection just to know the file is ready for write operations. Also, we never want to close the connection only to know the sending buffer capability.

No matter what you do, there are going to be error paths in file I/O.  Trying
to eliminate one of them won't make all of the others go away.  If you want to
know when WS is finished with a Blob, address that directly.

For example, add a "blob" attribute to onerror indicating which blob (if any)
the error is associated with, and add an onprogress event to WS with a similar
attribute.  If you have use cases for something like this, it should probably
be opened as a separate bug.

(The rest is a bit off-topic, explaining why locking won't work; reordered to
the bottom.)

> I believe all application including a browser are eligible to use lock in order
> to assure their internal operations.

First, this is unimplementable.  Mandatory locking is not allowed in Linux by
default; you have to enable it with a special mount option, "mand", which is
normally disabled.  You can't prevent external apps from writing to or deleting
files.

But there's a more basic issue: what you're suggesting is to lock the file so
long as you have a reference to a File (not only while reading from it). 
That's the only way to ensure that the file isn't deleted or modified between
the file being opened and the script calling send(blob).

It's OK to lock a file *while* you're actively accessing it, but that's not
what a File is.  A File is analogous to a pathname in a native application; it
can be kept around indefinitely, long before and after actual file access.  A
File can even be stored long-term via IndexedDB and the History API (to restore
open files across session reloads), though I think nobody implements those
features yet.

It's only actually being accessed while an API (FileReader, FileWriter,
WebSocket) is active on it--that's the only time locking makes sense.

-- 
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 Tuesday, 5 June 2012 16:08:50 UTC