Re: Overlap between StreamReader and FileReader

Here for the examples: 
http://lists.w3.org/Archives/Public/public-webapps/2013JulSep/0453.html

Simple ones leading to a simple Streams interface, I thought this was 
the spirit of the original Streams API proposal.

Now you want a stream interface so you can code some js like mspack on 
top of it.

I am still missing a part of the puzzle or how to use it: as you mention 
the stream is coming from somewhere (File, indexedDB, WebSocket, XHR, 
WebRTC, etc) you have a limited choice of APIs to get it, so msgpack 
will act on top of one of those APIs, no? (then back to the examples above)

How can you get the data another way?

Regards,

Aymeric

Le 13/09/2013 06:36, Takeshi Yoshino a écrit :
> On Fri, Sep 13, 2013 at 5:15 AM, Aymeric Vitte <vitteaymeric@gmail.com 
> <mailto:vitteaymeric@gmail.com>> wrote:
>
>     Isaac said too "So, just to be clear, I'm **not** suggesting that
>     browser streams copy Node streams verbatim.".
>
>
> I know. I wanted to kick the discussion which was stopped for 2 weeks.
>
>     Unless you want to do node inside browsers (which would be great
>     but seems unlikely) I still don't see the relation between this
>     kind of proposal and existing APIs.
>
>
> What do you mean by "existing APIs"? I was thinking that we've been 
> discussing what Stream read/write API for manual consuming/producing 
> by JavaScript code should be like.
>
>     Could you please give an example very different from the ones I
>     gave already?
>
>
> Sorry, which mail?
>
> One of what I was imaging is protocol parsing. Such as msgpack, 
> protocol buffer. It's good that ArrayBuffers of exact size is obtained.
>
> OTOH, as someone pointed out, Stream should have some flow control 
> mechanism not to pull unlimited amount of data from async storage, 
> network, etc. readableSize in my proposal is an example of how we make 
> the limit controllable by an app.
>
> We could also depend on the size argument of read() call. But thinking 
> of protocol parsing again, it's common that we have small fields such 
> as 4, 8, 16 bytes. If read(size) is configured to pull size bytes from 
> async storage, it's inefficient. Maybe we could have some hard coded 
> limit, e.g. 1MiB and use max(hardCodedLimit, requestedReadSize).
>
> I'm fine with the latter.
>
>     You have reverted to EventTarget too instead of promises, why?
>
>
> There was no intention to object against use of Promise. Sorry that I 
> wasn't clear. I'm rather interested in receiving sequence of data as 
> they become available (corresponds to Jonas's ChunkedData version read 
> methods) with just one read call. Sorry that I didn't mention 
> explicitly, but listeners on the proposed API came from ChunkedData 
> object. I thought we can put them on Stream itself by giving up 
> multiple read scenario.
>
> writeable/readableThreshold can be safely removed from the API if we 
> agree it's not important. If the threshold stuff are removed, flush() 
> and pull() will also be removed.
>

-- 
jCore
Email :  avitte@jcore.fr
Peersm : http://www.peersm.com
iAnonym : http://www.ianonym.com
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms
Web :    www.jcore.fr
Extract Widget Mobile : www.extractwidget.com
BlimpMe! : www.blimpme.com