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

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>> 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.

/Adam

Received on Thursday, 14 June 2012 15:53:10 UTC