Yes for the different questions, I first mentioned it in [1]
That's not an invention of mine, node is doing this:
var handle=function(req,res) {
var raw=fs.createReadStream(file);
res.writeHead(200,head);
//and the magic comes here:
raw.pipe(zlib.createGzip()).pipe(res);
};
http.createServer(handle).listen(80,function() {});
If the concept is correct and applicable (with promises), as previously
mentioned, a good example could be WebCrypto:
crypto.subtle.encrypt(aesAlgorithmEncrypt, aesKey, sourceStream).createStream()
So the WebCrypto API does not have to be modified and just need to
support the createStream method, so a two lines change in the spec.
Regards,
Aymeric
[1] http://lists.w3.org/Archives/Public/public-webapps/2013JulSep/0593.html
Le 04/11/2013 00:41, Feras Moussa a écrit :
Streams instantiations somewhere make me think to the structured clone
algorithm, as I proposed before there should be a method like a
createStream so you just need to say for a given API that it supports
this method and you don't have to modify the API except for specific
cases (xhr,ws,etc), like for the structured clone algo, and this is missing.
This is an interesting idea. But I'm not entirely clear on your proposal. Is
[1] where you mentioned it, or is there another thread I've missed?
You're not proposing changing the stream constructor, but rather also defining
a generic way an API can add support for stream by implementing a
strongly-defined createStream method?
Is your thinking to have this in order to give users a consistent way to obtain
a stream from various APIs?
On first thought I like the idea, but I think once we settle on a definition of
'Stream', we can asses what is really required for other APIs to begin
supporting it. If so, I can create a bug to track this concept.
[1] http://lists.w3.org/Archives/Public/public-webapps/2013OctDec/0246.html
----------------------------------------
Date: Sun, 3 Nov 2013 23:16:12 +0100
From: vitteayme...@gmail.com
To: art.bars...@nokia.com
CC: public-webapps@w3.org
Subject: Re: CfC: publish WD of Streams API; deadline Nov 3
Yes, with good results, groups are throwing the ball to others... I
don't know right now all the groups that might need to be involved,
that's the reason of my question.
4 days out without internet connection, usually one email every two
weeks on the subject and suddendly tons of emails, looks like a
conspiracy...
I will reread the threads (still perplex about some issues, a txt stream
is a binary stream that should be piped to textEncoder/Decoder from my
standpoint, making it a special case just complicates everything, maybe
it's too late to revert this) but it looks like the consensus is to wait
for Domenic's proposal, OK but as I mentioned he missed some points in
the current proposal and it's interesting to read carefully the Overlap
thread, and I find it important to have a simple way to handle
ArrayBuffer, View, Blob without converting all the time.
Streams instantiations somewhere make me think to the structured clone
algorithm, as I proposed before there should be a method like a
createStream so you just need to say for a given API that it supports
this method and you don't have to modify the API except for specific
cases (xhr,ws,etc), like for the structured clone algo, and this is missing.
Regards
Aymeric
Le 03/11/2013 19:02, Arthur Barstow a écrit :
Hi Aymeric,
On 10/29/13 7:22 AM, ext Aymeric Vitte wrote:
Who is coordinating each group that should get involved?
I thought you agreed to do that ;).
MediaStream for example should be based on the Stream interface and
all related streams proposals.
More seriously though, this is good to know, and if there is
additional coordination that needs to be done, please let us know.
-Thanks, ArtB
--
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
