Re: Request for feedback: Streams API

Hi,

Implementation of back pressure is important for handling large data
stably. The Streams need to ask the consumer code to notify it when it can
consume more data. Triggering this signal by method invocation is one of
possible options. Promises fit this well.

To address smaug___'s concern, we could choose not to 1-to-1 correspond
delivery of data and pull operation. Deliver data using callback
invocation, while allowing the consuming code to tell amount it want to
pull via pullAmount. Like WritableByteStream allows write() ignoring back
pressure, we allow ReadableByteStream to push available data to consuming
code ignoring back pressure. As far as the producer inside
WritableByteStream does work respecting pullAmount, back pressure mechanism
should still work well.

One concern Domenic showed in the chat will remain un-addressed. That is an
issue with callback setting timing. If we take "Promise read()" approach,
arrived data never vanishes into the void. I understand this
error-proneness.

Takeshi


On Mon, Dec 16, 2013 at 9:21 PM, Olli Pettay <Olli.Pettay@helsinki.fi>wrote:

> On 12/04/2013 06:27 PM, Feras Moussa wrote:
>
>> The editors of the Streams API have reached a milestone where we feel
>> many of the major issues that have been identified thus far are now
>> resolved and
>> incorporated in the editors draft.
>>
>> The editors draft [1] has been heavily updated and reviewed the past few
>> weeks to address all concerns raised, including:
>> 1. Separation into two distinct types -ReadableByteStream and
>> WritableByteStream
>> 2. Explicit support for back pressure management
>> 3. Improvements to help with pipe( ) and flow-control management
>> 4. Updated spec text and diagrams for further clarifications
>>
>> There are still a set of bugs being tracked in bugzilla. We would like
>> others to please review the updated proposal, and provide any feedback they
>> may
>> have (or file bugs).
>>
>> Thanks.
>> -Feras
>>
>>
>> [1] https://dvcs.w3.org/hg/streams-api/raw-file/tip/Overview.htm
>>
>
>
> So per https://www.w3.org/Bugs/Public/show_bug.cgi?id=24054
> it is not clear to me why the API is heavily Promise based.
> Event listeners tend to work better with stream like APIs.
>
>
> (The fact the Promises are hip atm is not a reason to use them for
> everything ;) )
>
> -Olli
>
>
>
>