- From: Roman Shpount <roman@telurix.com>
- Date: Wed, 17 Jul 2013 13:00:20 -0400
- To: Harald Alvestrand <harald@alvestrand.no>
- Cc: public-webrtc@w3.org
- Message-ID: <CAD5OKxv==29wqZ1g-pOU3+ctDxzcJkQXBgRSyCYfR-i1JkYtDg@mail.gmail.com>
On Wed, Jul 17, 2013 at 5:52 AM, Harald Alvestrand <harald@alvestrand.no>wrote: > That was the original rationale for exposing the SDP, actually; people > with exotic needs could get satisfaction without complexifying the API > interface, but in return, they had to do SDP munging. > > I do not think that the interface of the application with outside world and its support of exotic features is the issue. The issue are exotic and any new features implemented and exposed by the browser. Right now, in the SIP world, every time I deploy a new device I do the interop. Every time I update the device firmware or desktop software version, I do the interop. The model you propose would essentially mean that every time I deal with new browser, I will need to do the interop. Every time the browser updates, I will need to do the interop. Given the current browser update rates, this means that all I would have time to do would be interop testing my application and would have no time to develop any new features. Also, with each new browser version which is currently in use, the number of interop tests will group geometrically. I am not sure this is sustainable model unless the spec itself can guarantee that SDP implementations are interoperable. There are two ways to achieve it: make it very restrictive and be very careful about adding to it or do not put it into an API at all. _____________ Roman Shpount
Received on Wednesday, 17 July 2013 17:00:50 UTC