Re: Comments on version web-apps specs from 2013-10-31
Thanks for feedback. On Thu, Nov 21, 2013 at 4:56 PM, Feras Moussa wrote: > 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 Promise 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
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. > >
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(). 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? Section 3.2: 1. Shouldn't a FileWrite also be capable of consuming a Stream? (Like XHR-pipe-to-FileWriter) 2. Shouldn't an XMLHttpRequest also be capable of consuming a Stream? (eg. chunked PUT/POST)? 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.
