[Bug 17262] send function should have async interface

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

--- Comment #20 from Takashi Toyoshima <toyoshim@chromium.org> 2012-06-05 07:26:51 UTC ---
Note: This discussion looks out of scope to this thread.

(In reply to comment #19)
I believe all application including a browser are eligible to use lock in order
to assure their internal operations.

Should users have a chance to delete a file when they request the Explorer to
copy the file to another place and it's going on. I don't think so. An
application may gracefully provide a "Cancel" button. But it's a best case.

Uploading file looks a similar case. I agreed that lazy release caused by GC is
problematic. But it's another issue.

> Scripts must deal with errors anyway, as there will always be error cases for
> File.  This is just an error.

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.

Only way to send a data safely is to wait for bufferedAmount being zero becore
calling send(). Of course, it increases application level end to end
communication latency and decrease total message throughput.

-- 
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 07:26:58 UTC