RE: Super-academic, highly-abstract meta-modelling time: The Media Path

> From: Martin Thomson [mailto:martin.thomson@gmail.com]
> And it need not be "user action".  There could be any number of
> reasons why the operating mode of the source is forced to change.
> This is clearly the case where an 'onoverconstrained' event applies,
> which might just be better defined as 'onsettingschange' so
> applications can manage in-tab, cross-tab, cross-application and
> user-initiated changes in the same fashion.  The big question is
> whether the track ends, pauses, or continues with the modified (but
> conflicted) settings.  I agree, the last option give the application
> the choice, so I'd prefer to see that being the result.  A boolean
> flag on an 'onsettingschange' event indicating that the settings
> applied by this track are no longer all valid might be appropriate.
> Or, on the other extreme, a collection of the settings that changed,
> plus a collection of those that were broken.
> 
> This does have ramifications for some applications.  Any event is
> going to appear after the change has taken effect.  It's possible that
> some applications wont cope with these sorts of changes.  For example,
> the SBC might crash if you change video resolutions mid-stream. I'd
> like to hear screams before I added more API to deal with this sort of
> corner case though.

It seems to be very useful to have separate notifications for situations where the developer-supplied constraint is no longer workable by the source (overconstrained), but it's also useful just to know when settings change when there are no constraints in effect (such would be the case that the developer needs to update some UI showing the flash is now off when the user physically turns off the flash on the device). The only way to do that with the current V6 proposal (and I think this is an oversight in that proposal) is to continuously poll the state property to see when it changes (not a great option).

Received on Friday, 15 February 2013 19:33:04 UTC