Re: Thoughts behind the Streams API ED

On Fri, Nov 8, 2013 at 8:54 PM, Aymeric Vitte <vitteaymeric@gmail.com>wrote:

> I would expect "Poc" (stop, keep 0xd1 for the next data) and "сия"
>
> It can be seen a bit different indeed, while with crypto you expect the
> finalization of the operation since the begining (but only by computing the
> latest bytes), here you can not expect the string since the begining of
> course.
>
> It just depends how the "Operation" (here TextDecoder) handles stop but I
> find it very similar, TextEncoder closes the operation with the bytes it
> has and "clone" its state (ie do nothing here except clearing resolved
> bytes and keeping unresolved ones for data to come).
>

I'd say more generally that stop() is kinda in-band control signal that is
inserted between elements of the stream and distinguishable from the
elements. As you said, interpretation of the stop() symbol depends on what
the destination is.

One thing I'm still not sure is that I think you can just add stop()
equivalent method to the destination, and
- pipe() data until the point you were calling stop()
- call the stop() equivalent on e.g. hash
- restart pipe()

At least our spec allows for this. Of course, it's convenient that Stream
can carry such a signal. But there's trade-off between the convenience and
API size. Similar to decision whether we include abort() to
WritableByteStream or not.

Extremely, abort(), close() and stop() can be merged into one method
(unless abort() method has a functionality to abandon already written
data). They're all signal inserting methods.

close() -> signal(FIN)
stop(info) -> signal(CONTROL, info)
abort(error) -> signal(ABORT, error)

and the signal is packed and inserted into the stream's internal buffer.