Re: Web Audio API / WebRTC Integration

On Mon, Oct 17, 2011 at 4:29 PM, Robert O'Callahan <robert@ocallahan.org>wrote:

> On Tue, Oct 18, 2011 at 8:27 AM, Chris Rogers <crogers@google.com> wrote:
>
>> In object-oriented design, it is often better to avoid a monolithic
>> inheritance design where too many responsibilities are put into the API of a
>> single object type.  This can result in a "fragile base class" problem and
>> makes it difficult for the user of the API, and makes it much more difficult
>> to extend/modify the API in the future.  I believe this is a problem with
>> your approach.  Instead, a more modular design allows for APIs which can be
>> designed very precisely to address the special needs required by the use
>> cases.
>>
>
> My experience is that when two objects have a one-to-one relationship and
> represent the same abstraction, fusing them is almost always a good thing. I
> could talk about examples of this --- longstanding architectural warts in
> Gecko --- but I find OO design philosophy a bit subjective so I don't know
> who's going to be convinced either way here :-).
>
> I don't know of any other examples in the Web platform where we've
> deliberately split a single abstraction into multiple objects to reduce the
> API surface of each object.
>

Let me try an analogy here.  In the graphics world we have distinct entities
such as <img>, <canvas>, <svg>, <video>, ...,  and different JavaScript APIs
for dealing with these objects.  For <canvas> there are two different APIs
for drawing: canvas 2D, and WebGL.  In canvas 2D there's an entity called
ImageData which has a relationship with <img> and WebGL textures.  Canvas 2D
has other kinds of objects which manipulate pixels.  All of these APIs and
objects have relationships with one another, and can be used together to
great effect.  Then there's CSS which describes structural relationships,
etc.  So there are many different types of objects which each have targeted
APIs that can work well together.  There is no one-size-fits-all abstraction
for dealing with graphics, and there shouldn't be.

Similarly, audio is a complex medium.  It has many different aspects and
needs to be handled from the very highest levels down to the very lowest
with the appropriate API for each level.  The details of dealing with audio
at each of these levels is very particular, so I believe it's reasonable to
design an architecture with a structured API set where the various entities
can interact in powerful ways.

This is the approach I've taken with the Web Audio API.  I can't say that
the API or the implementation is perfect, but it's very much more than a
prototype at this point and I sincerely hope that people will consider it
seriously.  In terms of maturity, the API itself has undergone lots of
scrutiny over a period of more than a year.  It has working implementations
in multiple browsers on multiple platforms, has gone through intense
security review, and has a suite of layout tests.  And it's being stress
tested and put to good use by developers.  This is important because it's
good to know that an API can work in actual practice.

Designing an audio API from scratch without going through this process is
really hard to get right.

Chris