- From: Aymeric Vitte <vitteaymeric@gmail.com>
- Date: Fri, 08 Nov 2013 09:38:58 +0100
- To: Takeshi Yoshino <tyoshino@google.com>
- CC: "Web Applications Working Group WG (public-webapps@w3.org)" <public-webapps@w3.org>
- Message-ID: <527CA322.1090901@gmail.com>
Please see here https://github.com/whatwg/streams/issues/33, I realized that this would apply to operations like textDecoder too without the need of an explicit stream option, so that's no more WebCrypto only related. Regards Aymeric Le 07/11/2013 11:25, Aymeric Vitte a écrit : > > 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 -- Peersm : http://www.peersm.com node-Tor : https://www.github.com/Ayms/node-Tor GitHub : https://www.github.com/Ayms
Received on Friday, 8 November 2013 08:40:01 UTC