RE: Keeping up data channel

 

> -----Original Message-----
> From: Stefan Hakansson LK [mailto:stefan.lk.hakansson@ericsson.com] 
> Sent: den 13 juni 2012 08:12
> To: Martin Thomson
> Cc: public-webrtc@w3.org
> Subject: Re: Keeping up data channel
> 
> On 06/13/2012 01:01 AM, Martin Thomson wrote:
> > On 12 June 2012 13:15, Stefan Hakansson LK 
> > <stefan.lk.hakansson@ericsson.com>  wrote:
> >> I think we need to make developers close the 
> PeerConnection when it 
> >> is not needed. A way to promote this would of course be to make 
> >> PeerConnection set up fast.
> >
> > Unfortunately, responsiveness is also a trait that is valued highly.
> > Setup for data channels is currently prohibitively long.  
> Applications 
> > that are not specifically targeting mobile users will have abysmal 
> > performance on mobile networks initially.  Expect the radio 
> to remain 
> > on constantly.
> 
> Is there anything we could do? I was last night thinking 
> about: what if we added "disable" and "enable" to 
> PeerConnection. It would simplify for app developers since 
> incoming MediaStream objects (that they have attached to 
> video elements for display), DataChannel objects etc. would 
> remain in the app and would not have to be set up again.
> 
> However, this would not cure the responsiveness problem. Is 
> there anything that could be done there (perhaps in 
> combinations with "disable"; a PeerConnection that is in 
> state "disable" would be faster into "enable" than starting 
> from scratch)?
> 
> Another track is the new W3C CG on "Network-Friendly App and 
> WebApp Best Practices Community Group" 
> (http://www.w3.org/community/networkfriendly/). They produce 
> guidelines, and are also taking power consumption into 
> account. Perhaps we could add some text to their guidelines 
> at a later stage.


If we think this is important, we could do a informational/best practice kind of draft in this
or the IETF RTCWEB WG as a first step.

> 
> >
> > I expect that many developers will come down on the wrong 
> side of the 
> > tradeoff, especially since we give them such an awful set 
> of choices - 
> > massive latency or massive battery use.  Natural selection 
> of a sort 
> > will prevail.  I suspect that problems will surface pretty quickly.
> > Mobile applications that are bad at this tend to get a reputation 
> > pretty quickly and people stop using them.
> >
> > --Martin
> 
> 
>

Received on Wednesday, 13 June 2012 07:52:35 UTC