- From: <bugzilla@jessica.w3.org>
- Date: Fri, 08 Nov 2013 08:21:57 +0000
- To: public-webapps-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23772
Bug ID: 23772
Summary: Just return read result when there's data
synchronously readable
Product: WebAppsWG
Version: unspecified
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P2
Component: Streams API
Assignee: tyoshino@google.com
Reporter: tyoshino@google.com
QA Contact: public-webapps-bugzilla@w3.org
CC: mike@w3.org, public-webapps@w3.org
It's currently implemented in preview ver.
https://dvcs.w3.org/hg/streams-api/raw-file/tip/preview.html
ByteStreamReadResult.data is a Promise when no data synchronously readable.
Otherwise, data is actual data.
This is inspired by e.g. Chrome's network stack code (ERR_IO_PENDING).
----
It's efficient, but I got feedback against this from Elliott. Quoting.
- It's really weird that sometimes this thing is a Promise and sometimes it
isn't.
- It also doesn't make sense that the data property is a Promise since the size
and eof properties cannot be known until the promise is resolved so we might as
well return Promise<Result> instead of a Result with a Promise property and a
size/eof property external to it.
- Having the value jump between Promise and real data based on network latency
is going to be very error prone for authors, you can probably write your code
all one way if your network is fast and then see it fail when sometimes it's
slower.
- I'd suggest always returning a Promise and dealing with it at microtask time
for the "synchronous" case.
--
You are receiving this mail because:
You are the QA Contact for the bug.
Received on Friday, 8 November 2013 08:21:59 UTC