Re: Comments on version web-apps specs from 2013-10-31

2013-12-09 Thread Takeshi Yoshino
Thanks for feedback.

On Thu, Nov 21, 2013 at 4:56 PM, Feras Moussa feras.mou...@hotmail.comwrote:

 Hi Francois,
 Thanks for the feedback.


  From: francois-xavier.kowal...@hp.com
  To: public-webapps@w3.org
  Date: Wed, 20 Nov 2013 20:30:47 +
  Subject: Comments on version web-apps specs from 2013-10-31

 
  Hello
 
  I have a few comments on:
 https://dvcs.w3.org/hg/streams-api/raw-file/tip/Overview.htm from
 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.
 
  Section 2.1.3:
  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
 eof=true.


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.


 
  Section 3.2:
  1. Shouldn't a FileWrite also be capable of consuming a Stream? (Like
 XHR-pipe-to-FileWriter)
 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.


 
  br.
 
  —FiX
 
  PS: My request to join this group is pending, so please Cc me in any
 reply/comment you may have until membership is fixed.
 
 



RE: Comments on version web-apps specs from 2013-10-31

2013-11-20 Thread Feras Moussa
Hi Francois,Thanks for the feedback.

 From: francois-xavier.kowal...@hp.com
 To: public-webapps@w3.org
 Date: Wed, 20 Nov 2013 20:30:47 +
 Subject: Comments on version web-apps specs from 2013-10-31
 
 Hello
 
 I have a few comments on: 
 https://dvcs.w3.org/hg/streams-api/raw-file/tip/Overview.htm from 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.
 
 Section 2.1.3:
 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 eof=true.
 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?
 
 Section 3.2:
 1. Shouldn't a FileWrite also be capable of consuming a Stream? (Like 
 XHR-pipe-to-FileWriter)Yes, I think so - this is a use case we can add.
 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.
 
 br.
 
 —FiX
 
 PS: My request to join this group is pending, so please Cc me in any 
 reply/comment you may have until membership is fixed.