- From: Tim Panton <thp@westhawk.co.uk>
- Date: Fri, 15 Jun 2012 09:27:16 +0100
- To: Harald Alvestrand <harald@alvestrand.no>
- Cc: public-webrtc@w3.org
On 15 Jun 2012, at 07:41, Harald Alvestrand wrote: > On 06/14/2012 05:24 PM, Dominique Hazael-Massieux wrote: >> Le jeudi 14 juin 2012 à 11:19 -0400, Justin Uberti a écrit : >> >>> IceCandidate and SessionDescription represent different concepts. For >>> example, IceCandidate has a label attribute to indicate which media it >>> is relevant for (it's not just a DOMString). >> That might be the intent, but not what the current spec has; if there is >> a need for two strings, I suggest a dictionary rather than a full blown >> interface. >> >>> And SessionDescription will surely have methods in the future to make >>> handling SDP less messy. >> That's the part that I think was at least somewhat controversial during >> the F2F. > I was actually arguing hard *against* defining SDP manipulation methods in this version of the interface, but *for* keeping the SDP object so that we have the option of doing so in the future. > > Those of us who have still not grasped the intricacies of SDP (in whose numbers I count myself at least half the days of the week) need to have some working examples of code that manipulates SDP shown to them, with descriptions of why the manipulations were intrinsically necessary and not just a bug on one or the other side, before we should dare to think that we know what interfaces to design. > > +1 And I'd go further and say that of the multiple SDP manipulation libs that emerge in the next year or so, we should pick the one that a) works b) abstracts as far from SDP as is possible My goal here is to have the necessary flexibility in a clean API, but allow us to replace SDP with something better in the future. T. Tim Panton - Web/VoIP consultant and implementor www.westhawk.co.uk
Received on Friday, 15 June 2012 08:27:50 UTC