- From: Philip Jägenstedt via GitHub <sysbot+gh@w3.org>
- Date: Tue, 12 Jul 2016 10:00:37 +0000
- To: public-secondscreen@w3.org
I mean that the algorithm for picking a resource can be spelled out in detail unless diverging behavior is desirable or perhaps unavoidable. If it's left undefined, then sharing tests between implementations won't be possible because any behavior is allowed. The trouble with `canPlayType` is that sites can rely entirely on that instead of appending `source` child elements, in fact I'd guess that this is pretty common. In that case the resource selected for local playback will be the only one known to the "what should I play remotely" algorithm but it might be a resource that doesn't work remotely. How to make this work well depends on what the (internal) API for the remote side looks like. Will it be possible to try playing a resource and fall back to another if it fails to decode? That's what happens with `source` child elements, in particular when there's no `type` attribute it's the *only* way to find the resource that you support. My concern is that the `source` child elements will have two processing models: 1. The current model, where each `source` element is processed in tree order (with a "pointer" to keep track of which one to try next) and the first one that could work is tried. If it's a totally unsupported resource, the next `source` child is tried. 2. A model for remote, where at a single point in time, all `source` child elements are collected and turned into some representation sent to the remote. The *best* of these is used, and if it doesn't work the second best is tried, and so on. (Nobody has spelled out that remote would work like that, but it's tempting to do that.) -- GitHub Notification of comment by foolip Please view or discuss this issue at https://github.com/w3c/remote-playback/issues/7#issuecomment-231994522 using your GitHub account
Received on Tuesday, 12 July 2016 10:00:50 UTC