- From: Chris Lowis <chris.lowis@gmail.com>
- Date: Sun, 16 Feb 2014 15:20:01 +0000
- To: Audio WG <public-audio@w3.org>
Hi, There’s an action[1] on me to take a look at the issue raised last year[2] about how/whether the following methods should be defined on instances of offlineAudioContext: createMediaElementSource createMediaStreamSource createMediaStreamDestination At the moment offlineAudioContext is defined as a subclass of AudioContext. One option therefore is to override these methods to raise some kind of “unsupported” exception when called on an instance of offlineAudioContext. This doesn’t feel right to me. It’d be nicer if they simply didn’t exist on offlineAudioContext. There doesn’t seem to be a way to specify “composition” in webidl, so I cant think of a way of including them in AudioContext and leaving them out of offlineAudioContext. I could break the inheritance relationship and introduce some duplication between the two types of context in the spec. Alternatively, working with this reminded me of the point raised by the TAG[3] about introducing constructors for each of the node types, and having the factory methods on the contexts themselves available (through a library?) as “syntactic sugar”. This would be a breaking change, but it would certainly simplify the specification of the two types of context. Thoughts? Cheers, Chris PS - Paul, is your ReSpec branch[4] the defacto “master”? Should I create pull requests against it? [1] http://www.w3.org/2011/audio/track/actions/86 [2] http://lists.w3.org/Archives/Public/public-audio/2013OctDec/0200.html which spun out of this contribution to the Web Audio test suite: https://github.com/w3c/web-platform-tests/pull/396. [3] https://github.com/WebAudio/web-audio-api/issues/250 [4] https://github.com/WebAudio/web-audio-api/pull/272
Received on Sunday, 16 February 2014 15:20:31 UTC