Re: Thoughts behind the Streams API ED


See discussion here too:

The problem with stop again is that I need to handle myself the clone 
operations, the advantage of stop-eof is:

- clone the operation
- close it
- restart from the clone

And as I mentioned before this would work for any operation that has 
unresolved bytes (TextDecoder, etc) without the need of modifying the 
operation API for explicit clones or options.



Le 08/11/2013 14:31, Takeshi Yoshino a e'crit :
> On Fri, Nov 8, 2013 at 8:54 PM, Aymeric Vitte < 
> <>> 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.

Peersm :
node-Tor :
GitHub :

Received on Tuesday, 12 November 2013 08:20:49 UTC