W3C home > Mailing lists > Public > public-media-capture@w3.org > March 2013

Re: Rationalizing new/start/end/mute/unmute/enabled/disabled

From: Martin Thomson <martin.thomson@gmail.com>
Date: Mon, 25 Mar 2013 15:49:25 -0700
Message-ID: <CABkgnnWM53SB84C6uXkJeP-F91XC38T5Duht4KDSvfcRzEB+dg@mail.gmail.com>
To: Jim Barnett <Jim.Barnett@genesyslab.com>
Cc: "public-media-capture@w3.org" <public-media-capture@w3.org>
On 25 March 2013 15:34, Jim Barnett <Jim.Barnett@genesyslab.com> wrote:
> I think this is good.  A couple of questions:
> 1.  Why does MediaStream need a state at all?  Is it just a convenient shorthand for the combination of its Tracks' state?

I don't believe that it does need a state.  However, we did have a
discussion about this and some people expressed a desire for a
convenient rollup of state AND I've been warned off of re-opening
issues.

> 2.  Is it really simpler to have a single onstatechange handler?  The code inside every one of them will be a big case statement:  if started do this, if ended do this, etc.  I would think that you might get cleaner code by breaking each out into its own handler.  If we wrote a standard state machine diagram (UML or the  like) for a Track, it will show the individual started/ended events, and not a generic statechange event.  I realize that this may be just a matter of taste, but I think that the easier we make it for the programmer to visualize the UML statechart, the better the code will be.

I'm not really sure which is better.  I was simply looking for
consistency with other interfaces that we've built recently.

I don't use case statements any more anyway.  One advantage of having
fewer states on each state variable is that you can isolate logic.
Received on Monday, 25 March 2013 22:49:53 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:26:15 UTC