- From: Harald Alvestrand <harald@alvestrand.no>
- Date: Mon, 03 Mar 2014 08:32:20 +0100
- To: public-webrtc@w3.org
- Message-ID: <53143004.7090908@alvestrand.no>
On 03/03/2014 07:48 AM, Kiran Kumar wrote: > Hi Harald, > Thank you for your response. > > Actually, I missed the oniceconnectionstatechange while providing > above example, which will be covered by existing callbacks. > But AFAIK, single call-back to all the notifications which can > distinguish with a notification type enum or string, will be more > useful for extending the notifications in future. I think I disagree with this API design philosophy. Notification events (these aren't callbacks! sorry for abusing the terminology) need to carry the context for which they make sense; this may be carried in the event name or in the event argument, but needs to be carried all the same. If you jumble all events together under one event name, and then extend the API by adding new stuff happening under the old event name, you will have new events being fired at old handling code. This is unlikely (in my opinion) to be a Good Thing. > > Thanks, > Kiran. > > > On Fri, Feb 28, 2014 at 5:14 PM, Harald Alvestrand > <harald@alvestrand.no <mailto:harald@alvestrand.no>> wrote: > > On 02/27/2014 05:46 AM, Kiran Kumar wrote: > > Dear All, > > I would like to propose a NotificationCallback for RTCPeerConnection > > object. > > This is useful, for example, in following conditions. > > before doing so, it would be good to have your comments on the > existing > notification callbacks, of which there are several. > > > > 1. If connection is not established between the two peers within a > > specified time frame, then platform can convey the userAget > regarding > > the connection state. > > oniceconnectionstatechange? (checking -> failed, I think) > > > > 2. If connection state is expired in the middle of the session. > > etc. > > oniceconnectionstatechange? (connected -> disconnected) > > > > > Suggestions and Feedback welcome. > > > > Thanks, > > Kiran. > > > -- > Surveillance is pervasive. Go Dark. > > > -- Surveillance is pervasive. Go Dark.
Received on Monday, 3 March 2014 07:32:49 UTC