RE: Need to expose RTCSocket object

We could define that RTCConnection constructor does not require mandatory
RTCSocket argument and instead creates a new one which can be later
retrieved via getLocalSocket(). But we need something to clone the loaded
streams into a connection and share same local port, otherwise how to
implement forking?

BTW I do know that clone() requires more love and specification details,
but IMHO is, at least, a way to go for getting forking. We are open to any
other aproach anyhow.

Regards.

--
Iñaki Baz Castillo
<ibc@aliax.net>
El 31/08/2013 00:04, "Martin Thomson" <martin.thomson@skype.net> escribió:

> Because clone() is insufficient, complex and hard to reason about.
>  Clone() is currently underspecified, but if it is similar to the proposal
> made long back for JSEP, it's a partial clone of state, replicating only
> the local sockets and none of the additional state already accumulated
> (including remote candidates and any connection state).
>
> I've argued in the past that clone() should be removed.
>
> RTCSocket is invisible if you don't care for those complex use cases.
>
> > -----Original Message-----
> > From: Gustavo García [mailto:ggb@tokbox.com]
> > Sent: Thursday, 29 August, 2013 2:14
> > To: public-orca@w3.org
> > Subject: Need to expose RTCSocket object
> >
> > Could somebody explain why do we need to expose RTCSocket in the public
> > API "for serial and parallel media forking"?  Could we expose clone
> method
> > but keep RTCSocket as an internal implementation detail?
> >
> > I'm probably missing something.  Thank you for the info, G.
> >
> >
> >
>
>
>