Thanks for feedback.
On Thu, Nov 21, 2013 at 4:56 PM, Feras Moussa feras.mou...@hotmail.comwrote:
Thanks for the feedback.
Date: Wed, 20 Nov 2013 20:30:47 +
Subject: Comments on version web-apps specs from 2013-10-31
I have a few comments on:
2013-10-31. Apologies wether it is not the latest version: It took me some
time to figure-out where was the right forum to send these comments to.
1. Close(): For writeable streams, the close() method does not provide a
data-completion hook (all-data-flushed-to-destination), unlike the close
method that resolved the Promise returned by read().
The version of the spec you linked doesn't differentiate
writeable/readable streams, but is something we are considering adding in a
future version. I don't quite understand what you're referring to here.
close is independent of future reads - you can call a read after close, and
once EOF is reached, the promise is resolved and you get a result with
writeClose() we have now is still void.
In current API, fulfillment of writePromise doesn't necessarily mean
acknowledgement (data written has been successfully processed) but
implmentor may give such a meaning to it in the following two ways:
- fulfill writePromise when the written data is successfully consumed
- make writeClose return a Promise, say closePromise. writePromise may be
fulfilled before processing but writeClose is fulfilled only when all the
data written has been successfully consumed
I think it makes sense to change writeClose() type to Promiseundefined so
that derived classes may choose to use it to notify the writer of success.
2. Pipe(): the readable Steam (the one that provides the pipe() method)
is neutered in case of I/O error, but the state change of the writeable
stream is not indicated. What if the write operation failed?
Are you asking what the chain of error propagation is when multiple
streams are chained?
Error handling is not yet well documented but I plan to make write
operation failure result in rejection of pipePromise.
1. Shouldn't a FileWrite also be capable of consuming a Stream? (Like
Yes, I think so - this is a use case we can add.
Added to the possible consumer list.
2. Shouldn't an XMLHttpRequest also be capable of consuming a Stream?
(eg. chunked PUT/POST)?
Section 5.4 covers this - support for posting a Stream. That said, this is
a section I think will need to be flushed out more.
Added in recent commit.
PS: My request to join this group is pending, so please Cc me in any
reply/comment you may have until membership is fixed.