Re: Web Audio API / WebRTC Integration

On Tue, Oct 18, 2011 at 8:27 AM, Chris Rogers <crogers@google.com> wrote:

> In looking at the code examples, it's not clear that this is actually
> tangibly more complex.  In fact, I would argue the opposite.  Many of
> your processing examples invoke a worker with non-trivial JavaScript file
> (such as "spatializer.js") where you're hiding a considerable amount of code
> (hundreds to thousands of lines of JS) to implement the processing.  I would
> argue that this introduces unnecessary complexity, particularly for the very
> common use cases of games, interactive applications, and
> spatializing/filtering a peer's audio source in WebRTC applications.
>

The question is whether the processing code lives in the browser or a
Javascript library. I don't think having it in the browser necessarily
reduces complexity; in fact, it arguably increases complexity for everyone
because we have to specify and implement the exact processing semantics,
then authors have to deal with browser bugs and other differences and work
around mismatches between their needs and what was specified. However, I
agree that the cost is sometimes going to be worthwhile to get performance
gains.

I expect most authors to use canned processing libraries, and for them the
only issue is to make it very convenient to use a JS processing library, and
I think I've achieved that.

Anyway, this is orthogonal to the bridging issue.

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.

Rob
-- 
"If we claim to be without sin, we deceive ourselves and the truth is not in
us. If we confess our sins, he is faithful and just and will forgive us our
sins and purify us from all unrighteousness. If we claim we have not sinned,
we make him out to be a liar and his word is not in us." [1 John 1:8-10]