Apparently we are not talking about the same thing, while I am thinking
to a high level interface your interface is taking care of the
underlying level.
Like node's streams, node had to define it since it was not existing
(but is someone using node's streams as such or does everybody use the
higher levels (net, ssl/tls, http, https)?), I have been working since
quite some time on projects streaming things in all possible ways inside
browsers or with node and I never felt any need for such a proposal.
So, to understand where the mismatch comes from, could you please
highlight a web use case/code example based on your proposal?
Regards,
Aymeric
Le 11/09/2013 18:14, Takeshi Yoshino a écrit :
I forgot to add an attribute to specify the max size of backing store.
Maybe it should be added to the constructor.
On Wed, Sep 11, 2013 at 11:24 PM, Takeshi Yoshino <[email protected]
<mailto:[email protected]>> wrote:
any peek(optional [Clamp] long long size, optional [Clamp] long
long offset);
peek with offset doesn't make sense for text mode reading. Some
exception should be throw for that case.
- readableSize attribute returns (number of readable bytes as of
the last time the event loop started executing a task) - (bytes
consumed by read() method).
+ (bytes added by write() and transferred to read buffer synchronously)
----
The concept of this interface is
- to allow bulk transfer from internal asynchronous storage (e.g.
network, disk based backing store) to JS world but delay conversion
(e.g. into DOMString, ArrayBuffer).
- not to ask an app to do such transfer explicitly
--
jCore
Email : [email protected]
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
