Re: Thoughts behind the Streams API ED

Le 07/11/2013 10:42, Takeshi Yoshino a écrit :
> On Thu, Nov 7, 2013 at 6:27 PM, Aymeric Vitte <vitteaymeric@gmail.com 
> <mailto:vitteaymeric@gmail.com>> wrote:
>
>
>     Le 07/11/2013 10:21, Takeshi Yoshino a écrit :
>>     On Thu, Nov 7, 2013 at 6:05 PM, Aymeric Vitte
>>     <vitteaymeric@gmail.com <mailto:vitteaymeric@gmail.com>> wrote:
>>
>>         stop/resume:
>>
>>         Indeed as I mentioned this is related to WebCrypto Issue22
>>         but I don't think this is a unique case. Issue22 was closed
>>         because of lack of proposals to solve it, apparently I was
>>         the only one to care about it (but I saw recently some other
>>         messages that seem to be related), and finally this would
>>         involve a public clone method with associated security concerns.
>>
>>         But with Streams it could be different, the application will
>>         internally clone the state of the operation probably
>>         eliminating the security issues, as simple as that.
>>
>>         To describe simply the use case, let's take a progressive
>>         hash computing 4 bytes by 4 bytes:
>>
>>         incoming stream: ABCDE bytes
>>         hash operation: process ABCD, keep E for the next computation
>>         incoming stream: FGHI bytes + STOP-EOF
>>         hash operation: process EFGH, process STOP-EOF: clone the
>>         state of the hash, close the operation: digest hash with I
>>
>>
>>     So, here, partial hash for ABCDEFGH is output
>
>     No, you get the digest for ABCDEFGHI and you get a cloned
>     operation which will restart from ABCDEFGH
>
>
>
> OK.
>
>>
>>         resume:
>>         incoming stream: JKLF
>>         hash operation (clone): process IJKL, keep F for next computation
>>         etc...
>>
>>
>>     and if we close the stream here we'll get a hash for
>>     ABCDEFGHIJKLFPPP (P is padding). Right?
>
>     If you close the stream here you get the digest for ABCDEFGHIJKLF
>
>
> resume happens implicitly when new data comes in without explicit 
> method call say resume()?

Good question, I would say yes, so we don't need resume finally, but 
maybe others have different opinion, let's ask whatwg if they foresee 
this case.

>
>>         So you do not restart the operation as if it was the first
>>         time it was receiving data, you just continue it from the
>>         state it was when stop was received.
>>
>>         That's not so unusual to do this, it has been requested many
>>         times in node.
>>
>
>     -- 
>     Peersm :http://www.peersm.com
>     node-Tor :https://www.github.com/Ayms/node-Tor
>     GitHub :https://www.github.com/Ayms
>
>

-- 
Peersm : http://www.peersm.com
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms