- From: Francois Daoust <fd@w3.org>
- Date: Mon, 26 Sep 2016 14:36:25 +0200
- To: <public-secondscreen@w3.org>
Hi Second Screen WG,
I cleaned up the minutes of the first day of the Second Screen WG F2F last week in Lisbon. They are available at:
http://www.w3.org/2016/09/22-webscreens-minutes
... and copied as raw text below for archival. As you may have seen (I apologize for the series of emails that this triggered), I also added a link to the right part of the minutes from GitHub issues.
As usual, per charter, RESOLUTIONS that appear in the minutes are provisional until 10 working days after the publication of these minutes. Please use issues on GitHub to raise possible concerns on these resolutions.
Thanks,
Francois.
-----
Second Screen WG F2F - Day 1/2
22 Sep 2016
[2]Agenda
[2] https://www.w3.org/wiki/Second_Screen/Meetings/Sep_2016_F2F#Agenda
See also: [3]IRC log
[3] http://www.w3.org/2016/09/22-webscreens-irc
Attendees
Present
Anton_Vayvod(Google), Mark_Foltz(Google),
Anssi_Kostiainen(Intel), Shih-Chiang_Chien(Mozilla),
Mounir_Lamouri(Google), Eric_Carlson(Apple),
Mark_Watson(Netflix), Louay_Bassbouss(Fraunhofer),
Francois_Daoust(W3C), Hyojin_Song(LGE),
Kenneth_Christiansen(Intel), Hiroki_Endo(NHK),
Ingar_Arntzen(MotionCorporation),
Tomoyuki_Shimizu(KDDI), Chris_Needham(BBC),
Kasar_Masood(Viacom), Kumanan_Yogaratnam(Espial)
Chair
Anssi
Scribe
Francois, Mark
Contents
* [4]Topics
1. [5]Presentation API issues
1. [6]Clarify presentation ID generation
requirements (#346)
2. [7]Introduction could use some copy editing
(#345)
3. [8]Spec for PresentationConnectionCloseEvent
conflicts with note (#344)
4. [9]Establishing a presentation connection steps
do not handle failures (#343)
5. [10]Presentation display availability is not
clearly defined (#342)
6. [11]navigator.presentation is marked optional in
WebIDL (#341)
7. [12]Examples 5.6 does not need onconnect handler
(#340)
8. [13]setConnection in example 5.5 may put UI in an
inconsistent state (#339)
9. [14]PresentationConnectionList is not required
for receiving user agents (#337)
10. [15]PresentationRequest constructor uses entry
settings object (#336)
11. [16]Define the behavior for consecutive calls to
getAvailability (#335)
12. [17]Define that "TV" should appear as token for
UA-string (#303)
13. [18]Check references category and stability
(#295)
2. [19]Presentation API testing
3. [20]Implementation status
4. [21]Moving beyond CR
5. [22]Presentation API v2
1. [23]Cloud paired screens as presentation targets
(#61)
2. [24]Forced 1-UA mode for documents or frames
(#347)
3. [25]Allowing a page to turn itself in a
presentation session (#32)
4. [26]Can the same browsing context act as a
controller and a receiver? (#338)
5. [27]Compatibility with HbbTV (#67)
6. [28]Presentations without communication channel
(#202)
7. [29]Presentation display capability detection
(#348)
6. [30]Remote Playback API
1. [31]Implementation guidance for browsers that a
media element with controls is remoted (#48)
2. [32]Define the relation with Media Session spec
(#10)
3. [33]Guidance for HTMLMediaElement (#41)
* [34]Summary of Action Items
* [35]Summary of Resolutions
See also the [36]minutes of day 2.
__________________________________________________________
[36] http://www.w3.org/23-webscreens-minutes.html
Anssi: Welcome to the Second Screen WG 2016 TPAC F2F meeting!
... [agenda review]
... v1 issues for the Presentation API are the ones we want to
fix right away to move the Presentation API to REC. v2 issues
would be for a possible second version of the specification.
Anssi: The Presentation API spec got published as a Candidate
Recommendation in July 2016 (see [37]Presentation API
publication history).
... We'll shuffle the agenda a bit to discuss everything
related to v1 first, then talk about v2.
... We may also compact the agenda a bit to spend more time on
CG discussions around protocols.
[37] https://www.w3.org/standards/history/presentation-api
[quick round of introductions]
Presentation API issues
-> [38]Presentation API open issues
[38] https://github.com/w3c/presentation-api/issues?utf8=✓&q=is:issue is:open
Francois: Note some recent issues are not labeled as v1 or v2.
Anssi: Let's go through them
Clarify presentation ID generation requirements (#346)
-> [39]Clarify presentation ID generation requirements (#346)
[39] https://github.com/w3c/presentation-api/issues/346
Mark: We "recommend" to use UUID, We'd better use "SHOULD" to
clarify that this is a normative statement.
Francois: Why is that not a MUST? Do we anticipate good reasons
to create other types of UUID?
Mark: I think it can be a MUST. I think I can take an action to
research what other specs are doing.
Shih-Chiang: Just checked MediaStreams spec, they use SHOULD.
<scribe> ACTION: For #346, @mfoltzgoogle to check how other
specs reference UUID generation and adjust the spec accordingly
with SHOULD or MUST. [recorded in
[40]http://www.w3.org/2016/09/22-webscreens-minutes.html#action
01]
[40] http://www.w3.org/2016/09/22-webscreens-minutes.html#action01]
Introduction could use some copy editing (#345)
-> [41]Introduction could use some copy editing (#345)
[41] https://github.com/w3c/presentation-api/issues/345
Mark: Purely editorial.
Spec for PresentationConnectionCloseEvent conflicts with note (#344)
-> [42]Spec for PresentationConnectionCloseEvent conflicts with
note (#344)
[42] https://github.com/w3c/presentation-api/issues/344
Mark: The examples in the note do not include the reason why
the error occurred, whereas we recommend that.
... We should update the examples in the note.
<mfoltzgoogle> ACTION: For #344, Mark to update close message
examples to conform to spec. [recorded in
[43]http://www.w3.org/2016/09/22-webscreens-minutes.html#action
04]
[43] http://www.w3.org/2016/09/22-webscreens-minutes.html#action04]
Establishing a presentation connection steps do not handle failures
(#343)
-> [44]Establishing a presentation connection steps do not
handle failures (#343)
[44] https://github.com/w3c/presentation-api/issues/343
Mark: I'm suggesting moving the error handling part from the
start connection algorithm into the establish a connection
algorithm so that the reconnect algorithm also benefits from
it.
... Also, the note in 6.5.1 is not explicit about which steps
can be automatically retried.
Anssi: Are there cases where implementations may not want to
retry?
Mark: That's a good question
... It depends on whether we want the developer to be fully
responsible for error handling.
Anssi: I think good general principle is that the developer
should always expect things to fail. Do we have implementation
feedback?
Mark: I don't think the connection will ever go from an error
state to a connected state without the developer having to do
something about it.
Anssi: OK, so that's per spec. The note is more an
implementation guideline.
... My mental model says that it's more intuitive to expose the
error right away to the developer. That would suggest dropping
the note.
Mark: I think I agree. I need to check whether that matches
implementation.
Anssi: Similar to a discussion we had in the Device and Sensors
WG around transient states.
... Anyone has concerns with dropping the note?
RESOLUTION: For #343, move error handling steps from the start
algorithm to the establish a connection algorithm, and remove
the note in 6.5.1 about retrying connection establishment.
Presentation display availability is not clearly defined (#342)
-> [45]Presentation display availability is not clearly defined
(#342)
[45] https://github.com/w3c/presentation-api/issues/342
Mark: I wonder whether that's an idiom we need to define, or is
it just a reference to the object that we need.
Anssi: I think that's just a way to have an English name. This
seems like a style issue. I would leave it to the editor.
Mark: We may need some idiom to say exactly what this means.
Francois: Personally, I agree it would be better to have a
proper definition. I don't think there's a clear guideline
across Web specs on this.
Mark: I do want to check that there is some proper definition
of what availability means.
<mfoltzgoogle> ACTION: For #342, Mark to check that there is a
proper definition of "availability." [recorded in
[46]http://www.w3.org/2016/09/22-webscreens-minutes.html#action
03]
[46] http://www.w3.org/2016/09/22-webscreens-minutes.html#action03]
navigator.presentation is marked optional in WebIDL (#341)
-> [47]navigator.presentation is marked optional in WebIDL
(#341)
[47] https://github.com/w3c/presentation-api/issues/341
Mark: I think that's an IDL bug, the presentation attribute
cannot be null in practice.
RESOLUTION: For #341, make "navigator.presentation" attribute
mandatory to align with the normative prose.
Examples 5.6 does not need onconnect handler (#340)
-> [48]Examples 5.6 does not need onconnect handler (#340)
[48] https://github.com/w3c/presentation-api/issues/340
Anssi: Editorial, needs fixing.
setConnection in example 5.5 may put UI in an inconsistent state
(#339)
-> [49]setConnection in example 5.5 may put UI in an
inconsistent state (#339)
[49] https://github.com/w3c/presentation-api/issues/339
<scribe> ACTION: Kenneth to review and fix the example in 5.5
[recorded in
[50]http://www.w3.org/2016/09/22-webscreens-minutes.html#action
02]
[50] http://www.w3.org/2016/09/22-webscreens-minutes.html#action02]
PresentationConnectionList is not required for receiving user agents
(#337)
-> [51]PresentationConnectionList is not required for receiving
user agents (#337)
[51] https://github.com/w3c/presentation-api/issues/337
Mark: The Conformance section lists mandatory interfaces, but
PresentationConnectionList fell through the cracks.
RESOLUTION: For #337, add PresentationConnectionList to the
list of interfaces to be supported by receiving user agents.
Anssi: Moving on to older v1 issues
PresentationRequest constructor uses entry settings object (#336)
-> [52]PresentationRequest constructor uses entry settings
object (#336)
[52] https://github.com/w3c/presentation-api/issues/336
Anssi: Basically, things changed in HTML, and we should align.
[looking at another spec which fixed this, seems to use
"incumbent object"]
Anssi: We need to look at how other specs have been refactored
and follow that practice.
Francois: We could add ourselves to the [53]list of specs
tracked to reduce the use of "entry settings object" and ping
Domenic about that.
[53] https://github.com/whatwg/html/issues/1431
RESOLUTION: For #336, examine how other specs have been updated
to use the settings object and update our spec to match.
Define the behavior for consecutive calls to getAvailability (#335)
-> [54]Define the behavior for consecutive calls to
getAvailability (#335)
[54] https://github.com/w3c/presentation-api/issues/335
Shih-Chiang: The availability object will be created during the
first call. Different unclear behavior. When are promises
resolved when consecutive calls to getAvailability are issued?
Anssi: In the battery context, multiple calls will yield the
same Promise (see [55]Battery promise).
[55] https://w3c.github.io/battery/#dfn-battery-promise
Mounir: I think we should add a new step after step 6 to reuse
an existing Promise if there's one.
Anssi: that would be a one-liner fix
Francois: About the first bullet, my understanding is that the
problem is that different contexts cannot return the same JS
object.
Mark: Yes, they would have to be different JS objects. I think
we need to be clear about when we refer to script objects or
internal objects.
... I'll check our implementation but indeed, different calls
to getAvailability from different contexts will return
different script objects that are in the same internal state.
... I think we should check when we say promise or availability
object whether we refer to a script object or an internal
state, and make that consistent throughout the spec.
... The IDL has [SameObject], so enforces the fact that the
same script object gets returned in a given browsing context.
... Actually the [SameObject] attribute is not there, so we
need to be explicit about that.
Francois: Also, note that for bullet 2, we're missing "in
parallel" in step 9.
RESOLUTION: For #335, check algorithms around availability
objects and make sure they all refer to "script object" or
"internal object". For bullet 2, add "in parallel" in step 9.
For bullet 3, make sure getAvailability returns the same
Promise object.
Define that "TV" should appear as token for UA-string (#303)
-> [56]Define that "TV" should appear as token for UA-string
(#303)
[56] https://github.com/w3c/presentation-api/issues/303
Anssi: Jonas is not around for the time being.
... Do we have new information?
Mark: I'm fine either way, provided we understand what TV
means. There seems to be a set of features, e.g. overscan,
input, resolution, etc.
Kenneth: It's not recommended to do UA sniffing at well.
... Reality is that people have to do sniffing from time to
time.
Anton: In the receiving context, the "receiver" attribute will
be set, so the application knows it is a presentation.
Francois: Right, that's what I raised in the GitHub issue as
well.
Anssi: I see, so that seems functionally equivalent.
... An app can do feature detection through that attribute and
react based on this. Additional specific CSS media queries
could be useful in the future.
RESOLUTION: For #303, add a note about feature detection
through the "receiver" attribute, no guideline on the UA
string.
Check references category and stability (#295)
-> [57]Check references category and stability (#295)
[57] https://github.com/w3c/presentation-api/issues/295
Francois: Basic rule is that a PR/REC cannot reference anything
else than a PR or a REC. In practice, there are exceptions to
the rule. We'll switch to HTML5.1, have a slight problem with
NotAllowedError in WebIDL, mixed content and permissions, as
well as a couple of specs references in the "Creating a
receiving browsing context" algorithm, but we're only
referencing high-level concepts there, no deep integration.
... We just need to keep track of those, and ensure we
highlight exceptions we need when we request transition to PR.
Presentation API testing
Anssi: We need to demonstrate interop to go to PR, and for that
we need to create a test suite.
... We should look at the current state and see what needs to
be done.
... Louay is test facilitator. Some contributions from
students, WG participants, Francois prepared a human-readable
[58]test coverage document.
[58] https://tidoust.github.io/presentation-api-testcoverage/#plan
Anssi: Proposed action plan for how to proceed with testing.
Three milestones to complete tests.
Anssi: End of October, work on existing tests and [59]fix open
issues. Four minor issues.
... For each missing test, create an issue in
web-platform-tests/presentation-api. Assign issues to test
writers.
... If there is a normative change, editor should ping Louay
and the test author that tests need to be updated.
... Need to move Chromecast app ids to a config file to avoid
duplication.
... Two web pages are registered with Fraunhofer accounts. Not
allowed to publish with our account.
... Need account to maintain published apps.
... W3C can create account to publish.
[59] https://github.com/w3c/web-platform-tests/labels/presentation-api
<scribe> ACTION: Francois to investigate creation of Cast
developer account to publish test app. [recorded in
[60]http://www.w3.org/2016/09/22-webscreens-minutes.html#action
05]
[60] http://www.w3.org/2016/09/22-webscreens-minutes.html#action05]
Louay: How to test different implementations (1-UA and 2-UA) in
the same user agent and present a consolidated report.
Anssi: What is the status of 1UA?
<anssik>
[61]https://tidoust.github.io/presentation-api-testcoverage/#ta
ble
[61] https://tidoust.github.io/presentation-api-testcoverage/#table
Mark: The bread of the sandwich is done. The yummy parts in the
middle are in progress.
Anssi: How to forward JSON test results from receiver?
Anssi/Mark: Cleaner to POST these to a separate service than to
use the presentation connection.
Mark_Watson: Test harness spawns windows, may not work in a
single-window environment.
Louay: Controller runs test on receiver, so don't need to spawn
windows.
Francois/Louay review test coverage report. Goal is to prepare
implementation report by the end of the December.
Anssi: Move coverage report to w3c repo?
Francois: Not part of test suite. Anssi: Leave as-is.
<tidoust> [FYI, iframe tests use a [62]stash.py file to store
test results on the server]
[62] https://github.com/w3c/web-platform-tests/blob/master/html/semantics/embedded-content/the-iframe-element/stash.py
Louay: Can check scripts to stash results. Or use WebSockets to
exchange test results.
Anton: Would a test receiver help that opens a window? Mark:
Mocks out the receiver, could be useful for testing controller.
Louay: Call for test contributors. Tomoyuki: Offers to help.
Implementation status
Mark presents Google Cast for Education, intended for class
rooms. Could be used for 1-UA mode as well as for 2-UA mode
Virtual screen access control goes through cloud. Mark gives
access to Anton, who shares images. Implementation is a proof
of concept not a full 2-UA implementation, it does not support
multiple controllers for instance. The receiving API needs to
be implemented.
The spec was not an obstacle to implement this. There's a
little bit of work to do around security.
The device runs Chrome OS. The stack is different from the
stack in Chromecast. The receiver part is a Chrome app. Being a
Chrome app helps leveraging some useful features such as user
login.
Mark mentioned the fact that Chrome shipped support for the
Cast API which is built on top of the Presentation API under
the hood.
The only plan for native implementation of receiver mode is
1-UA mode for Google.
Shih-Chiang shows a demo of Mozilla's implementation of the
Presentation API using a Firefox OS TV simulator.
Device selection part is currently missing from the
implementation. The TV simulator gets told to open the Web
page. It exposes the receiving API to the Web page that gets
loaded.
Louay wonders whether the TV simulator can be used for testing
the receiving side. The TV simulator is not publicly available.
<Tomoyuki> [FYI: [63]Simulating Firefox OS for TV on your
desktop (MDN)]
[63] https://developer.mozilla.org/en-US/docs/Mozilla/Firefox_OS_for_TV/Simulating_Firefox_OS_for_TV
Tomoyuki sees a public simulator, but it is an old version of
the simulator.
Kumanan wonders about underlying protocols. Proprietary
protocols are used. Topic will be discussed in the Second
Screen CG tomorrow. Mark points out that Google Cast for
Education does not really use the Cast protocol despite the
name, but a cloud-based protocol.
Moving beyond CR
Anssi reviews the requirements to transition beyond CR.
A discussion around re-chartering milestones follows. Is Q1
2017 too optimistic? If the group needs to publish a new CR, it
only has until mid-January 2017.
Shih-Chiang mentions Q1 2017 as implementation target for 1-UA
mode. Mark says he targets end of the year for 1-UA mode as
well. 2-UA mode is not going to be until Q1 2017.
2-UA mode is part of our CR exit criteria. It is work in
progress in Firefox OS for TV, with no clear ETA for shipping
at this stage.
Participants agree that Q2 2017 seems a better target for
completion.
[lunch break]
Presentation API v2
Anssi: Goal is to take version 1, fork it and start baking in
new features.
... Let's look at v2 issues and see whether that triggers
"excitment".
Cloud paired screens as presentation targets (#61)
-> [64]Cloud paired screens as presentation targets (#61)
[64] https://github.com/w3c/presentation-api/issues/61
Mark: I think flashing out the requirements to do that would be
useful.
Shih-Chiang: All of our envisioned developments so far target
the local network. It would be useful to let the user decide on
whether it allows a cloud-based screen that the app can
interact with instead of trying to agree on a mechanism to
achieve that.
... WebRTC already has a mechanism for pairing two devices,
maybe it would be easier for us to leverage this.
... i.e. reuse the signaling channel.
Mark: Also, it could be useful to repurpose an RTCDataChannel
for use in the Presentation API not for developers to change
it.
... Worth investigating
Forced 1-UA mode for documents or frames (#347)
-> [65]Forced 1-UA mode for documents or frames (#347)
[65] https://github.com/w3c/presentation-api/issues/347
Mark: In some cases, the controller may be the powerful end,
and power may be needed. Or low-latency is needed (e.g. in
gaming)
... Two possible options: 1/ a possibility to require 1-UA
mode, 2/ a new API to present an offscreen frame or canvas
(being able to access and control the remote DOM tree)
... The second part could be similar to requestFullscreen. A
kind of requestOffscreen. It's like a simpler use case for the
Presentation API.
... There's already some work being done in Chrome at least to
turn a canvas into a MediaStream, so the first part could build
on it.
Anssi: That reminds me of the [66]Offscreen canvas proposal
discussed in WHAT WG.
[66] https://wiki.whatwg.org/wiki/OffscreenCanvas
Allowing a page to turn itself in a presentation session (#32)
-> [67]Allowing a page to turn itself in a presentation session
(#32)
[67] https://github.com/w3c/presentation-api/issues/32
Mark: I think this use case is interesting. A device could pass
by and become a controlling user agent for a presentation
initially started on its own.
Anssi: How would you bootstrap this? NFC tapping?
Mark: It depends on context. For public devices, restrictions
are obviously needed.
Can the same browsing context act as a controller and a receiver?
(#338)
-> [68]Can the same browsing context act as a controller and a
receiver? (#338)
[68] https://github.com/w3c/presentation-api/issues/338
Mark: Problem is around the restrictions the spec places on a
receiving browsing context.
... The spec does not prevent that case, but we may need to
check the implications carefully.
... Also, you may need a way to delegate permissions if the
receiving user agent does not support user input as such.
Francois: The use case is somewhat different from a controlling
page willing to spawn a presentation on "as many screens as
possible".
Mark: Somewhat related though. The first presentation could
spawn another presentation. There are pros and cons to both
approaches.
Louay: The video wall use case comes to mind.
Ingar: Sync in this use case is typically within the scope of
the Multi-Device Timing CG. That does not solve the
bootstrapping problem.
Compatibility with HbbTV (#67)
-> [69]Compatibility with HbbTV (#67)
[69] https://github.com/w3c/presentation-api/issues/67
Francois: Part of CG discussions now.
Presentations without communication channel (#202)
-> [70]Presentations without communication channel (#202)
[70] https://github.com/w3c/presentation-api/issues/202
Francois: Some overlap with the "offscreen" idea.
Francois: This could allow for some bootstrapping scenarios,
e.g. where the user uses NFC tapping to pass the URL. No
communication channel can be established, but both ends can go
through the backend to communicate.
Presentation display capability detection (#348)
-> [71]Presentation display capability detection (#348)
[71] https://github.com/w3c/presentation-api/issues/348
<mfoltzgoogle> [72]Media capture from canvas
[72] https://www.w3.org/TR/mediacapture-fromelement/#html-canvas-element-media-capture-extensions
Mark: There may be different categories such as physical
attributes, media capabilities, support for specific APIs (MSE,
EME) or codecs, etc.
Anssi: HTMLMediaElement, getUserMedia come to mind for
capabilities detection.
Mark: Higher priority should be around features that are
independent of the content, so I/O characteristics typically.
... It might be expressed preferences. Controller could say "I
would work better if I had this or that capability". Usability
enhancement.
Mounir: Having that as preferences has issues. You may want to
ensure that you don't get some of the remote devices show up in
the list.
Mounir and Mark discuss preferences vs. constraints.
One issue is that this would leak more information to the app
through "getAvailability".
Anssi: A good approach would be to look at concrete use cases.
Keeping it simple is much better. "Input", etc.
Chris: When I discussed this internally, the discussion quickly
turned into codecs.
Mounir: It's more an issue for the Remote Playback API.
Anssi: Looking at the streams API now.
Mark: Domenic and I look at it as streams evolve. No concrete
action so far.
Anssi: Concluding this discussion, there seems to be valid use
cases for v2. None of this should make its way to v1.
... Our new draft charter would allow us to work on this.
<mfoltzgoogle> FYI: [73]<canvas>.captureStream() has shipped in
Chrome.
[73] https://www.chromestatus.com/features/4817998447640576
Remote Playback API
Anssi: Looking at post-FPWD issues.
Implementation guidance for browsers that a media element with
controls is remoted (#48)
-> [74]Implementation guidance for browsers that a media
element with controls is remoted (#48)
[74] https://github.com/w3c/remote-playback/issues/48
Anton: Some suggestion to convey that remoting is happening and
that some poster image should be displayed.
Anssi: I think different implementations convey things
differently. We can add a note.
Mark: From a privacy point of view, it seems important to
ensure the user is aware that something is happening remotely.
Chris: Or would you have an event about remoting changes of
state?
Anton: You will get events.
Anssi: The user should always be notified about what is
happening.
... Generally, it is a bad idea to specify anything specific to
UI in a spec.
Anton: The spec does not say whether the local playback should
be paused.
Anssi: I would not force the local playback to pause. That can
be useful in some cases.
Francois: It seems important to ensure that the app developer
knows whether the local playback is still running or not.
... Also, you probably do not want the local audio rendering to
continue, because synchronization will be very hard to achieve.
Anton: Except in the case where you want to watch a video in
two different rooms, you probably want to pause local playback.
Anssi: So should we expose a way to know whether the local
playback is still running?
Mounir: I think the spec should be explicit that local playback
needs to be paused.
Francois: Yes, if the developer wants to continue playback, he
can create another media element and handle the synchronization
on his own.
Anssi: OK.
Anton: From the point of view of the page, the media will still
be playing.
Define the relation with Media Session spec (#10)
-> [75]Define the relation with Media Session spec (#10)
[75] https://github.com/w3c/remote-playback/issues/10
Anton: We're waiting on media session to move forward.
Mounir: We re-scoped this effort and transitioned to WICG.
Anton: So only action is to wait until the spec matures and
revisits.
Guidance for HTMLMediaElement (#41)
-> [76]Guidance for HTMLMediaElement (#41)
[76] https://github.com/w3c/remote-playback/issues/41
Anton: The issue is that media element is like a big interface.
What should work and what should not work in the remote state?
... I've started to list what needs or does not need to be
supported.
Francois: Interesting, because it looks like a "profile" of the
HTMLMediaElement interface, which makes perfect sense, but may
not please some people.
Kumanan: Feature detection is already used to detect whether
some of these features are supported in the simple local case.
... You may not be able to seek for instance, and you cannot
ask more than what the remote device can achieve.
... In the set-top box case, there may be legal restrictions
for some of these features.
Anton: OK, so we should be careful for some of these MUST.
... we'll get to details tomorrow.
See the [77]minutes of day 2.
[77] http://www.w3.org/23-webscreens-minutes.html
Summary of Action Items
[NEW] ACTION: For #346, @mfoltzgoogle to check how other specs
reference UUID generation and adjust the spec accordingly with
SHOULD or MUST. [recorded in
[78]http://www.w3.org/2016/09/22-webscreens-minutes.html#action
01]
[NEW] ACTION: For #342, Mark to check that there is a proper
definition of "availability." [recorded in
[79]http://www.w3.org/2016/09/22-webscreens-minutes.html#action
03]
[NEW] ACTION: For #344, Mark to update close message examples
to conform to spec. [recorded in
[80]http://www.w3.org/2016/09/22-webscreens-minutes.html#action
04]
[NEW] ACTION: Francois to investigate creation of Cast
developer account to publish test app. [recorded in
[81]http://www.w3.org/2016/09/22-webscreens-minutes.html#action
05]
[NEW] ACTION: Kenneth to review and fix the example in 5.5
[recorded in
[82]http://www.w3.org/2016/09/22-webscreens-minutes.html#action
02]
[78] http://www.w3.org/2016/09/22-webscreens-minutes.html#action01
[79] http://www.w3.org/2016/09/22-webscreens-minutes.html#action03
[80] http://www.w3.org/2016/09/22-webscreens-minutes.html#action04
[81] http://www.w3.org/2016/09/22-webscreens-minutes.html#action05
[82] http://www.w3.org/2016/09/22-webscreens-minutes.html#action02
Summary of Resolutions
1. [83]For #343, move error handling steps from the start
algorithm to the establish a connection algorithm, and
remove the note in 6.5.1 about retrying connection
establishment.
2. [84]For #341, make "navigator.presentation" attribute
mandatory to align with the normative prose.
3. [85]For #337, add PresentationConnectionList to the list of
interfaces to be supported by receiving user agents.
4. [86]For #336, examine how other specs have been updated to
use the settings object and update our spec to match.
5. [87]For #335, check algorithms around availability objects
and make sure they all refer to "script object" or
"internal object". For bullet 2, add "in parallel" in step
9. For bullet 3, make sure getAvailability returns the same
Promise object.
6. [88]For #303, add a note about feature detection through
the "receiver" attribute, no guideline on the UA string.
[End of minutes]
Received on Monday, 26 September 2016 12:36:45 UTC