- From: Francois Daoust <fd@w3.org>
- Date: Mon, 12 Jan 2015 12:04:14 +0100
- To: "mark a. foltz" <mfoltz@google.com>
- CC: "Kostiainen, Anssi" <anssi.kostiainen@intel.com>, "Rottsches, Dominik" <dominik.rottsches@intel.com>, "public-webscreens@w3.org" <public-webscreens@w3.org>, "public-secondscreen@w3.org" <public-secondscreen@w3.org>, Anton Vayvod <avayvod@google.com>, Mark Scott <markdavidscott@google.com>
Hi Mark, I created issues in GitHub accordingly. On resumption of multiple sessions, you said: > Instead, if we would like to allow resumption of multiple > sessions that > share a URL+ID, then several changes would be required: > - The user agent would need to assign an internal unique > identifier to > each presentation (or to each screen) so it could track them using > something other than URL+ID. > - joinSession() would resolve to an array of > PresentationSessions in > case there were multiple matches. > I replied: > Perhaps we can leave that as an open issue for the time being and > focus on main use cases that involve presenting content on only one > second screen first. I created issue #39 to keep track of this: https://github.com/w3c/presentation-api/issues/39 [...] On screen availability and multiple sessions, you said: > There is nothing preventing a page from requesting multiple sessions > now, although it doesn't have a way to force the user to select a > second, unused screen (or to even know if there is an additional screen > available). You are correct that we would need to provide more > visibility into the status of all screens to support this use case cleanly. > > Do you feel like we should incorporate this question into a new Github > issue? I created issue #40 and note that issue #1 raises the question of multi-screen support as well: https://github.com/w3c/presentation-api/issues/40 https://github.com/w3c/presentation-api/issues/1 On the semantics of close(), you said: > Has the semantics of close() been discussed in the CG or WG yet? It > could mean one of three things: > > (1) Disconnect this PresentationSession (and only this > PresentationSession) from the presentation. > (2) Disconnect all PresentationSessions known by this user agent from > the presentation. > (3) Request that the second screen cancel the presentation (and, if > successful, will result in #2). > > We can go with (1), which is the most conservative approach, but doesn't > give a page any way to actually stop a presentation itself. Either the > user agent would provide a mechanism, or it could message the > presentation document to call window.close(). I'm fine with that > approach (it's consistent with the UX we have for Cast) but I'm curious > to hear other thoughts. All good points. For tracking purpose, I would say this is broadly captured under issue #35: https://github.com/w3c/presentation-api/issues/35 Thanks, Francois.
Received on Monday, 12 January 2015 11:04:50 UTC