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 13:46:50 UTC