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 <feras.moussa@hotmail.com>wrote:

> Hi Francois,
> Thanks for the feedback.
>
>
> > From: francois-xavier.kowalski@hp.com
> > To: public-webapps@w3.org
> > Date: Wed, 20 Nov 2013 20:30:47 +0000
> > 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<undefined> 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.
> >
> >
>