[Bug 17262] send function should have async interface

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

--- Comment #6 from Glenn Maynard <glenn@zewt.org> 2012-05-31 14:04:04 UTC ---
(In reply to comment #4)
> Blob's are read-only and can't be changed

With the exception of neutering (eg. structured clone transfer and, if it's
added, Blob.close).  All that's needed to deal with this exception is for async
APIs to synchronously take a reference to the underlying data of a Blob (or
File) before returning to the caller, not a reference to the Blob itself.  For
example, XHR.send() says "Let the request entity body be the raw data
represented by data."

(I'm not sure that this concept is well-defined enough.  Here, XHR wants to
take a conceptual reference to the underlying data, not actually read it from
disk if it's a File.)

(In reply to comment #0)
>  2. Queue the requested blob as a reference internally, then return from send
> operation immediately.
> 
> Choice 2 has another critical problem. JavaScript has no chance to know when
> the queued blob can be
> reusable. It means that JavaScript never modify the blob after passing to
> WebSocket send operation.

JavaScript can never modify blobs anyway, by design.

This seems like the right thing to do, with the caveat that when the actual
Blob read happens, it might fail.  I don't know the WebSocket API and usage
enough to know if simply reporting an error is good enough, and what should
happen to any data queued afterwards.

> Also, this choice makes bufferedAmount meaningless because limitation by
> internal buffer never depends buffer size.

I'm not sure what you mean.  After calling send(File), bufferedAmount is
increased by the file's length, which is always known in advance without any
disk I/O.  (Some browsers don't implement this correctly yet, but that's a
bug.)  As the file is streamed from disk over the network, bufferedAmount is
decreased.  The buffer size is usually not actually that big, but it seems like
reasonable behavior.

(In reply to comment #5)
> File inherits Blob, so we can send File object via these APIs.
> Of course, the file may provide another FileWriter interface to modify the
> actual file contents.

Actually, File is read-only, too.  More accurately, it's immutable (again with
the exception of neutering).

If the underlying File changes (whether by another application or FileWriter),
reads to earlier File instances will fail, not return the changed data.  A File
represents a snapshot of a file on disk at the time the File was created, and
if that data is no longer available because the file was modified, the read
fails.

-- 
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 Thursday, 31 May 2012 14:04:13 UTC