Re: [ACTION-43] (sdp related objects and global namespace) - way forward

On Thu, Jun 14, 2012 at 11:52 AM, Adam Bergkvist <
adam.bergkvist@ericsson.com> wrote:

> On 2012-06-14 17:19, Justin Uberti wrote:
>
>>
>>
>> On Thu, Jun 14, 2012 at 11:08 AM, Adam Bergkvist
>> <adam.bergkvist@ericsson.com <mailto:adam.bergkvist@**ericsson.com<adam.bergkvist@ericsson.com>>>
>> wrote:
>>
>>    On 2012-06-14 14:15, Dominique Hazael-Massieux wrote:
>>
>>        Hi Adam,
>>
>>        Le jeudi 14 juin 2012 à 12:06 +0200, Adam Bergkvist a écrit :
>>
>>            I got the task to drive action ACTION-43: Move
>>            SessionDescription and
>>            IceCandidate out of the global namespace.
>>
>>
>>        My recommendation would be:
>>        * to kill IceCandidate and replace it by a DOMString since we
>>        never use
>>        it for anything else as far as I can tell;
>>
>>        * if we must keep SessionDescription (which I understand there
>>        was rough
>>        consensus on, although I'm still not sure what for), we should
>>        make it a
>>        [NoInterfaceObject] interface, without constructor; if we need to
>>        construct the objects rather than just passing them around, we
>>        should
>>        have a factory function on PeerConnection  (e.g.
>>        pc.getSessionDescription) — but based on my recollection, there was
>>        still doubts on what we would use these objects for
>>
>>
>>    Perhaps we could settle with just one object. It would have a type
>>    attribute that could be "candidate" as well as the current
>>    SessionDescription types. I believe a requirement on the factory
>>    method is to be able to take a string received from the network.
>>    Otherwise it wouldn't be a direct replacement for the constructor
>>    (if that's what we need).
>>
>>
>> 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). And SessionDescription will
>> surely have methods in the future to make handling SDP less messy.
>>
>> Combining them to save a namespace name seems like the wrong optimization.
>>
>
> I don't want to combine them to get rid of an object in the global
> namespace (primarily). I think there are benefits.
>
> One object with a type attribute nice to have on the receiving side to
> switch on if the app wants to do different things with the different
> message types.
>
> I think it would be more OK to require an object as the argument to the
> function consuming the message on the receiver side when there's only one
> type. I.e., there's no need to have conditions on which type of object to
> create.
>
> A SessionDescription, as it is defined today, may very well have candidate
> lines included if, e.g., the developer has waited for candidates before
> creating the offer. Any API working with candidates would apply in both
> cases.
>
> A complete SDP, in the candidate case, would solve the problem with
> correlating candidates with the appropriate m-lines.


It's just a candidate - how can it be a complete SDP? The app needs access
to just the candidate information so it can turn that into a candidate
message in the appropriate signaling protocol.

If we made it a SDP fragment (m= + a=candidate),  this would mean that some
SessionDescriptions are full SDPs and others are partial SDPs, with unclear
benefit.