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

It sounds like we basically agree.  If the MediaStream is a convenient roll-up, then we should be sure to insert prose saying that the MediaStream's state is computed from its Tracks' states (making it clear that it has no independent meaning.)  It would probably also be good to change 'ended' to something like 'inactive'.  I know it's Easter week, but in general things that are 'ended' don't come back to life, and an ended/inactive MediaStream can go back to being active if a live track is added to it.

- Jim

-----Original Message-----
From: Martin Thomson [mailto:martin.thomson@gmail.com] 
Sent: Monday, March 25, 2013 6:49 PM
To: Jim Barnett
Cc: public-media-capture@w3.org
Subject: Re: Rationalizing new/start/end/mute/unmute/enabled/disabled

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 Tuesday, 26 March 2013 01:28:37 UTC