W3C home > Mailing lists > Public > public-webrtc@w3.org > June 2012

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

From: Cullen Jennings (fluffy) <fluffy@cisco.com>
Date: Mon, 18 Jun 2012 18:56:52 +0000
To: Justin Uberti <juberti@google.com>
CC: Harald Alvestrand <harald@alvestrand.no>, Anant Narayanan <anant@mozilla.com>, Adam Bergkvist <adam.bergkvist@ericsson.com>, "Dominique Hazael-Massieux" <dom@w3.org>, "public-webrtc@w3.org" <public-webrtc@w3.org>
Message-ID: <430248DA-A8B3-4597-AEC9-4CC2A249FB0C@cisco.com>

I'd be fine with prefixing everything with Rtc so it becomes




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 

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.
Received on Monday, 18 June 2012 18:57:22 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:28 UTC