- From: tim panton <thp@westhawk.co.uk>
- Date: Wed, 3 Jul 2013 08:48:39 +0100
- To: "Suhas Nandakumar (snandaku)" <snandaku@cisco.com>
- Cc: Iņaki Baz Castillo <ibc@aliax.net>, Ted Hardie <ted.ietf@gmail.com>, Christer Holmberg <christer.holmberg@ericsson.com>, cowwoc <cowwoc@bbs.darktech.org>, Robin Raymond <robin@hookflash.com>, "Roman Shpount" <roman@telurix.com>, Adam Bergkvist <adam.bergkvist@ericsson.com>, "piranna@gmail.com" <piranna@gmail.com>, "public-webrtc@w3.org" <public-webrtc@w3.org>, Eric Rescorla <ekr@rtfm.com>
On 3 Jul 2013, at 08:10, "Suhas Nandakumar (snandaku)" <snandaku@cisco.com> wrote: > > > Sent from my iPhone > > On Jul 3, 2013, at 12:02 AM, "tim panton" <thp@westhawk.co.uk> wrote: > >> >> On 3 Jul 2013, at 00:51, "Suhas Nandakumar (snandaku)" <snandaku@cisco.com> wrote: >> >> >> The W3C standard describes what the browser API looks like to the javascript developer. >> >> It defines what the developer has to do to set up a peer-connection with a set of desired properties. >> The way the javascript programmer determines what those desired properties are is up to her. >> Likewise the way the desired properties are communicated from one end to the other(s) can be >> independent of the API. >> >> Those properties will be derived 5 places : >> 1) from the local user's wishes, >> 2) from the capabilities of the local hardware, >> 3) from the service's policies, >> 4) from the remote hardware capabilities, >> 5) from the remote users wishes >> >> Our current API surface (SDP) is good at expressing 2) and 4) but weak at expressing the other sources, especially 3) >> >> Tim. >> > > Hello Tim > > I would be interested in learning about minimally extending existing API or constraints to solve the use cases that aren't covered by 1 and 3. Also 5 is can be covered within existing API and data model semantics > I believed that a year ago. I'm less convinced now. > My 2 cents > > Cheers > Suhas
Received on Wednesday, 3 July 2013 07:49:04 UTC