Re: SDP wrapper? Object-oriented API?

I'm really for an structured object with signaling properties over an 
SDP string and I think most of the people who actually wants to use SDP 
will benefit from such a change.

In the pure browser-to-browser case it doesn't matter if you're sending 
some string (or serialized object) between the browsers. As long as the 
other browser understands the string we're home. However, if you want to 
use SDP, it's not very likely that the WebRTC SDP is compatible with the 
rest of your system. So you need to parse it into a format where you can 
modify it, and then serialize it back to the desired SDP. With a 
structured signaling object, half of that work would be done for you.

/Adam

On 2013-06-17 00:23, cowwoc wrote:
> Hi Jim,
>
>      I'm asking for a WebRTC-specific API. The entire point is to
> abstract away the complexity of SDP and enable us to replace it in the
> future. To be clear, I'm asking for a high-level abstraction of the
> key/value pairs you're stuffing into SDP (and please don't use
> terminology specific to SDP, think higher level).
>
>      You could implement it by simply renaming "sdp" everywhere in the
> API to "PeerCapabilities" (still returned by createOffer(),
> createAnswer()) but then add class methods for manipulating the contents.
>
> Gili
>
> On 16/06/2013 5:57 PM, Jim Barnett wrote:
>> We have to decide what kind of API we want.  I see some people asking
>> for an object oriented layer that would keep them from having to edit
>> SDP by hand.  Something like that might start with an SDP object that
>> had properties int numMLines and an array mLines[mLine], where mLine
>> was an object with properties port, package, etc.
>>
>> I think that an API like this would be useful.  (The argument against
>> it has been that we shouldn't spend time on it because  someone will
>> write an SDP library.)  However that API is quite specific to SDP, and
>> I doubt that it would allow us to swap in another representation in a
>> later release.   An API that completely hid the underlying
>> representation would be much more challenging.  Maybe add
>> transport-related properties to MediaStreams and Tracks, and then have
>> a toOffer/toAnswer method on MediaStream, but that API/representation
>> would be closely tied to webRTC.
>>
>> SDP may stink, but a lot of people  outside webRTC seem to hold their
>> noses and use it...
>>
>> - Jim
>> P.S.  I'd be willing to work on either version of an API, but first
>> we'd have to decide that we are willing to cram it into release 1.  So
>> far, it hasn't  made the cut.
>>
>> -----Original Message-----
>> From: cowwoc [mailto:cowwoc@bbs.darktech.org]
>> Sent: Friday, June 14, 2013 11:58 PM
>> To: Suhas Nandakumar (snandaku)
>> Cc: public-webrtc@w3.org
>> Subject: Re: SDP wrapper? Object-oriented API?
>>
>>
>>       An object wrapper would be nice but it wasn't really the point I
>> was trying to make.
>>
>>       My point is that if SDP really is an implementation detail then
>> the specification must ensure that we can swap it out for something
>> else in the future without breaking backwards compatibility. To me,
>> that begins by specifying that the SDP argument is an opaque token.
>> WebRTC 1.0 might use SDP while WebRTC 2.0 might use some other format.
>>
>> Gili
>>
>> On 14/06/2013 11:47 PM, Suhas Nandakumar (snandaku) wrote:
>>> My 2 cents ..
>>>
>>> I personally dont feel why would one want to modify SDP frequently
>>> than supporting few special cases. Also once the APIs, SDP Usages and
>>> constraints are finalized, i envision there will be much lesser need
>>> to modify SDP by hand.
>>>
>>> Needing to have a object wrapper is fine by not sure if it is a MUST
>>> requirement.
>>>
>>>
>>> Cheers
>>> Suhas
>>>
>>> ________________________________________
>>> From: cowwoc [cowwoc@bbs.darktech.org]
>>> Sent: Friday, June 14, 2013 6:10 PM
>>> To: public-webrtc@w3.org
>>> Subject: Re: SDP wrapper? Object-oriented API?
>>>
>>>        +1. I understand that the spec authors are determined to stick
>>> with SDP and that's okay, but can we get the specification to
>>> explicitly state that SDP arguments are to be treated as read-only
>>> opaque tokens at this time? This leaves the door open to providing an
>>> object-oriented API for mutating SDP at some future time.
>>>
>>> Gili
>>>
>>> On 14/06/2013 3:14 PM, piranna@gmail.com wrote:
>>>> Isn't there somewhere a wrapper for SDPs? It's crazy trying to work
>>>> with them, and nothing have been decided yet about using a more
>>>> object-oriented API that modify the SPD strings by hand, while it has
>>>> been agreed several times on this list about SDPs should be
>>>> implementation detail... Also, such wrapper should be a basis where
>>>> to start to develop that higher-level API...
>>>>
>>>> --
>>>> "Si quieres viajar alrededor del mundo y ser invitado a hablar en un
>>>> monton de sitios diferentes, simplemente escribe un sistema operativo
>>>> Unix."
>>>> - Linus Tordvals, creador del sistema operativo Linux
>>>>
>>
>>
>
>

Received on Monday, 17 June 2013 12:27:58 UTC