RE: CfC: publish WD of Streams API; deadline Nov 3

2013-11-03 Thread Feras Moussa 
> 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
>
>

Re: Overlap between StreamReader and FileReader

2013-11-03 Thread Aymeric Vitte 

The idea did not come from mimicing WebRTC:

- pause/unpause: insert pause in the stream, stop processing the data 
when pause is reached (but don't close the operation, see below), buffer 
next data coming in, restart from pause on unpause


Use case: flow control, window flow control gets empty, wait signal from 
the receiver to reinitialize the window and restart


- stop/resume : different from close, stop: insert a specific eof-stop 
in the stream, the API closes the operation while receiving it, buffer 
data, restart the operation on resume in the state it was before 
receiving eof-stop


It's more tricky, use case is the one I gave before: specific 
progressive hash, close a hash and resume it from the state it was 
before closing it, the feature has been asked several time to node for 
example.


Whether it's "implementable", I don't know, but I don't see why it could 
not be, uses cases are real (myself but I am not the only one)


Regards,

Aymeric

Le 30/10/2013 12:49, Takeshi Yoshino a écrit :
On Wed, Oct 30, 2013 at 8:14 PM, Takeshi Yoshino > wrote:


On Wed, Oct 23, 2013 at 11:42 PM, Aymeric Vitte
mailto:vitteayme...@gmail.com>> wrote:

- pause: pause the stream, do not send eof



Sorry, what will be paused? Output?


http://lists.w3.org/Archives/Public/public-webrtc/2013Oct/0059.html
http://www.w3.org/2011/04/webrtc/wiki/Transport_Control#Pause.2Fresume

So, you're suggesting that we make Stream be a convenient point where 
we can dam up data flow and skip adding methods to pausing data 
producing and consuming to producer/consumer APIs? I.e. we make it 
able to prevent data queued in a Stream from being read. This 
typically means asynchronously suspending ongoing pipe() or read() 
call on the Stream with no-argument or very large argument.


- unpause: restart the stream

And flow control should be back and explicit, not sure right
now how to define it but I think it's impossible for a js app
to do a precise flow control, and for existing APIs like
WebSockets it's not easy to control the flow and avoid in some
situations to overload the UA.



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

Re: CfC: publish WD of Streams API; deadline Nov 3

2013-11-03 Thread Aymeric Vitte 
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

Re: CfC: publish WD of Streams API; deadline Nov 3

2013-11-03 Thread Arthur Barstow 

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

Re: CfC: publish WD of Streams API; deadline Nov 3

2013-11-03 Thread Arthur Barstow 

On 11/1/13 8:52 AM, ext Arthur Barstow wrote:

On 10/31/13 11:52 PM, ext Feras Moussa wrote:
Agreed. Some of the points listed appear to be things already 
addressed. Takeshi and I have some feedback on the initial mail, but 
will wait and provide thoughts on the proposal instead. Looking 
forward to seeing it.




From: tyosh...@google.com
Date: Fri, 1 Nov 2013 12:18:47 +0900
To: ann...@annevk.nl
CC: dome...@domenicdenicola.com; art.bars...@nokia.com; 
public-webapps@w3.org

Subject: Re: publish WD of Streams API; deadline Nov 3

OK. There seems to be some disconnect, but I'm fine with waiting for
Domenic's proposal first.



Feras, Takeshi - for the sake of clarity, are you proposing this CfC 
be stopped? [FWIW, I don't feel strongly either way, although I 
suspect one could argue that getting some additional exposure and 
comments could be helpful.]


Feras and Takeshi indicated they would like this CfC to continue, 
especially since their merged specs include improvements over the FPWD 
published 14-Feb-2013.


If people have technical comments on the latest ED, please send them to 
public-webapps and/or file bugs [Bugs].


-Thanks, ArtB

[Bugs]