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

On Mon, Jun 18, 2012 at 2:56 PM, Cullen Jennings (fluffy)
<fluffy@cisco.com>wrote:

>
> I'd be fine with prefixing everything with Rtc so it becomes
>
> RtcPeerConnection
>
> RtcSessionDescription
>
> etc.
>
> The key issues in my mind is that we get it so that it is very unlikely we
> will have a conflict in the shared namespace
>

Agree with this - there seems to be good precedent for using prefixes for
this purpose.

Of the prefixes proposed, I prefer either WebRTCXXXX or RTCXXXX over
PeerXXXX or PeerConnectionXXXX.

>
>
> On Jun 18, 2012, at 7:45 AM, Justin Uberti wrote:
>
> >
> >
> > On Mon, Jun 18, 2012 at 7:51 AM, Harald Alvestrand <harald@alvestrand.no>
> wrote:
> > On 06/16/2012 06:57 AM, Anant Narayanan wrote:
> > On 06/14/2012 03:06 AM, Adam Bergkvist wrote:
> > Ways forward:
> > ...
> > 2. Add, e.g., SessionDescription to the PeerConnection namespace.
> > * PeerConnection.SessionDescription
> > - Does any other web API do this?
> >
> > Downside with the two above is a very long name and, unlike e.g.
> > PeerConnectionErrorCallback, the name will be used by developers to
> > construct objects.
> >
> > My vote is for (2) as stated above. I'm not too worried about it being
> too long. If developers find themselves constructing this object often,
> they can set it at the top of the file:
> >
> > const SD = PeerConnection.SessionDescription;
> > const IC = PeerConnection.ICECandidate;
> > ...
> > var foo = new SD();
> > var bar = new IC();
> >
> > Regards,
> > -Anant
> >
> > 2 questions:
> >
> > 1) Anant, can you write out how this should be specified in WebIDL? It's
> not obvious to me that it's even possible to write an interface inside
> another interface.
> >
> > 2) Everyone else - do you have a strong opinion on this one way or the
> other? I'm in two minds myself on the namespace issue (it doesn't help if
> we're purists if everyone else goes the other way); if it's just Anant and
> half of me who think this is an issue, then we should go with stability
> rather than change.
> >
> > Looking over some related specs, I see a pretty clear precedent to do
> interface prefixing with the API name, or an abbreviation thereof:
> > WebGL: WebGLBuffer, WebGLProgram, WebGLShader, etc
> > IndexedDB: IDBDatabase, IDBRequest, IDBObjectStore, etc
> > WebAudio: AudioNode, AudioParam, AudioBuffer, etc
> >
> > As far as possible prefixes go, I prefer WebRTCFoo to PeerConnectionFoo.
>
>