07:04:06 <RRSAgent> RRSAgent has joined #webscreens
07:04:06 <RRSAgent> logging to http://www.w3.org/2015/05/20-webscreens-irc
07:04:14 <tidoust> RRSAgent, make logs public
07:04:38 <hongki> hongki has joined #webscreens
07:04:59 <tidoust> Meeting: Second Screen Presentation WG F2F - Berlin - Day
07:05:07 <tidoust> Chair: Anssi Kostiainen
07:05:23 <tidoust> Agenda: https://www.w3.org/wiki/Second_Screen/Meetings/May_2015_F2F#Day_2_-_Wed_20_May_2015
07:05:50 <obeletski> obeletski has joined #webscreens
07:07:06 <tidoust> Present: Anssi_Kostiainen, Mohammed_Dadas, Matt_Hammond, Oleg_Beletski, Hongki_Cha, Christian_Fuhrhop, Mark_Foltz, Anton_Vayvod, Shih-Chiang_Chien, Mark_Watson, Francois_Daoust, Jean-Claude_Dufourd
07:07:47 <mdadas> mdadas has joined #webscreens
07:08:00 <Zakim> Zakim has joined #webscreens
07:09:27 <tidoust> Anssi: Welcome back. See email I sent this morning. Proposed resolutions and actions manually labeled on GitHub.*
07:09:39 <tidoust> ... [Looking at the agenda]
07:10:58 <tidoust> Matt: agree to postpone agenda topic on HbbTV as already addressed to some extent during day 1 and distilled in other issues, so fine not to have it as a priority topic today
07:12:15 <tidoust> Mark_Foltz: Some progress to show on designating a default presentation URL and on presenting the content of an <audio> and <video> element
07:12:35 <tidoust> Anssi: OK, let's reorder topics then.
07:12:44 <tidoust> i/Anssi: Welcome back/scribe: tidoust/
07:12:51 <tidoust> Meeting: Second Screen Presentation WG F2F - Berlin - Day 2
07:12:55 <tidoust> RRSAgent, draft minutes
07:12:55 <RRSAgent> I have made the request to generate http://www.w3.org/2015/05/20-webscreens-minutes.html tidoust
07:14:04 <tidoust> Topic: Rethinking availability monitoring
07:14:10 <mfoltzgoogle> mfoltzgoogle has joined #webscreens
07:14:23 <tidoust> -> https://github.com/w3c/presentation-api/issues/81 Issue #81
07:15:25 <tidoust> Anssi: Trying to make developers life easy, availability monitoring was using a bit of an anti-pattern. Anton discussed with Mounir, Oleg and Mark Watson raised additional comments.
07:17:48 <tidoust> Mark_Foltz: Idea is, instead of having a global onavailablechange event, you would construct an event listener with "listenForAvailability" and then you either call "getAvailability" on that listener for a one-time use or attach an event listener to the onavailablechange property
07:18:02 <tidoust> ... I did not have time to write code for that but that seems to work.
07:18:46 <jcdufourd> jcdufourd has joined #webscreens
07:18:46 <tidoust> ... The use case to check periodically for screens availability one time had not come up before. Our experience is that screens availability is something dynamic, especially if you are using a mobile phone.
07:19:03 <tidoust> ... I would like to understand the use case for the one shot better.
07:19:14 <tidoust> Anssi: I can probably explain the use case I had in mind.
07:19:27 <obeletski> q+
07:20:18 <tidoust> ... "Find out whether there are available display(s), and if yes, show content on the display chosen by the user". My expectation was that the Web developer would just want to check for availability, and whenever there is a screen available, do something, else take another route.
07:22:05 <tidoust> ... Let's take an example of a Web page that wants to project another Web page on a big screen. It would call "getAvailability", and when it resolves, you start the session, which prompts the user.
07:23:25 <tidoust> Mark_Watson: The idea is to display a "present" button when there are screens available. To do that, you have to start monitoring for screens as soon as the page loads and keep monitoring for changes afterwards
07:23:30 <tidoust> ack ol
07:23:39 <tidoust> ack obe
07:24:53 <tidoust> Oleg_Beletski: Same thing for Samsung where the button is greyed out. If you only need a one shot thing, you don't really need to start monitoring, startSession would be enough, would trigger monitoring and you don't need to monitor screens availability.
07:26:48 <anssik> q?
07:34:00 <anssik> http://w3c.github.io/presentation-api/#starting-a-presentation-session
07:34:59 <mfoltzgoogle> mfoltzgoogle has joined #webscreens
07:35:45 <tidoust> tidoust has joined #webscreens
07:36:09 <tidoust> Mark_Watson: So, startSession handles this, but some way to monitor available screens in the background would be pretty useful. Problem is enabling continuous monitoring when an event handler is attached to a property is considered bad practice, right?
07:36:13 <tidoust> Mark_Foltz: right.
07:36:16 <tidoust> Anssi: Adding an event listener should not have side effect, that's a shared practice.
07:36:23 <tidoust> Mark_Foltz: So, how does geolocation handle this?
07:36:34 <tidoust> Anssi: Example of the deviceOrientation. If your phone is staying flat and you attach an event listener, you will not get an event up until the phone moves. The spec cannot force the user agent to fire an event when the event listener is attached.
07:36:42 <tidoust> Mark_Foltz: OK, back to my proposal, we could have an "available" boolean property. Then you may want some way to dismiss the listener to stop monitoring.
07:36:47 <tidoust> Anssi: listenForAvailability could be getAvailability that returns an AvailabilityObserver that has a boolean and fires an "availablechange" event when the property changes.
07:36:52 <tidoust> Anton: It's up to the user-agent to stop discovery when the page goes to sleep. No need to explicitly close the event.
07:39:04 <tidoust> Mark_Watson: wondering about the need to have "onavailablechange" when you already have addEventListener, removeEventListener
07:39:29 <tidoust> Anssi: Mostly legacy. This is the way Web is working. The "on" way of attaching events is sometimes useful.
07:41:00 <tidoust> Oleg: During the lifecycle of the application, you may switch from one to two screens, then back to one, and so on. Monitoring available screens is an expensive process. Having a way to cancel the monitoring would be good.
07:41:49 <tidoust> Anssi: We should leave it up to user agents to implement "continuous" the way they want, meaning adjusting the frequency of discovery or prompting the user after some time for instance.
07:42:38 <tidoust> Oleg: I think discovery is the most costly operation in Miracast for instance
07:44:23 <tidoust> Anssi: My expectation is that you could get an availability observer with an available property set to "false" and that we would not mandate the user agent to run discovery in the background as such. The user agent could wait for the device to be plugged in before it resumes discovery for instance.
07:44:30 <tidoust> ... That would be an acceptable implementation.
07:45:30 <tidoust> Oleg: I would still prefer to have a "cancel" method but we can add wording to warn developers that discovery can last until the end of the page lifetime. In geolocation, there is a way to stop listening.
07:45:39 <tidoust> Anssi: but not everyone does that.
07:46:17 <tidoust> ... If you have a loop which alternates start/stop, it could be more costly for the device than just continuous monitoring.
07:48:23 <tidoust> Francois: Do we agree that calling listenForAvailability repeatedly will not trigger multiple discovery under the hood?
07:48:40 <tidoust> Anton: Yes
07:49:21 <tidoust> Mark_Watson: Note the spec should clarify that multiple calls to listenForAvailability must return different objects.
07:50:29 <tidoust> Schien: I'm fine with the direction currently discussed. One question I have is on the "params" parameter.
07:50:51 <tidoust> Anssi: Right, let's discuss this in the next agenda topic.
07:51:15 <anssik> q?
07:51:16 <tidoust> Anton: in Samsung, does discovery run only when you display the list?
07:51:21 <tidoust> Oleg: I think so, yes.
07:52:45 <tidoust> Mark_Foltz: We may want to make a small amendment to reject the promise if the device does not support continuous background monitoring then.
07:53:00 <tidoust> Anssi: I like it, yes.
07:53:30 <tidoust> ... I think we're in agreement, updating the examples in sync with the changes would be good.
07:56:33 <tidoust> PROPOSED RESOLUTION: For issue #81, adopt proposal to have a "getAvailability" method on NavigatorPresentation that returns a Promise to get an AvailabilityListener (or observer) with a boolean "available" property and an "availablechange" event. Promise is rejected when user agent does not support background monitoring. startSession triggers discovery. No requirement on frequency of discovery (there may not be any in some period of time)
07:57:45 <mfoltzgoogle> mfoltzgoogle: One more thing: Ensure we specify how many AvailabilityListener objects get created when listenForAvailability() is called more than once.
07:58:14 <tidoust> ACTION: Anton to update startSession example to use implicit discovery (pending pull request)
08:00:04 <tidoust> ACTION: Oleg to clarify implicit/explicit mechanisms in the spec, and review the relevant algorithms and examples.
08:00:57 <tidoust> Topic: How to filter available screens according to the content being presented
08:01:05 <tidoust> -> https://github.com/w3c/presentation-api/issues/9 Issue #9
08:02:08 <tidoust> Mark_Watson: Idea is to be able to filter screens that cannot display the content that you would want to display. Specifically relevent for DIAL apps for instance. You want to provide the URL at the beginning of the discovery.
08:02:31 <tidoust> ... With the default presentation URL mechanism, this is actually covered.
08:02:45 <tidoust> Matt_Hammond: should we have a programmatic version as well?
08:03:11 <tidoust> Mark_Watson: In that case, the "getAvailability" method that we just discussed would address that.
08:04:01 <tidoust> Anssi: Generally, on the Web Platform, the developer tries things before he can know whether things work or not. This is a bit of departure.
08:05:08 <tidoust> Mark_Watson: You're not making the promise that it will work, you're just ensuring that pages know when it won't work
08:06:01 <tidoust> Jean-Claude: How would you know that the required app would be there?
08:06:11 <anssik> http://www.w3.org/TR/html5/embedded-content-0.html#dom-navigator-canplaytype
08:06:30 <tidoust> Mark_Watson: In the case of DIAL, it's the responsibility of DIAL to specify how to discover the app.
08:07:04 <tidoust> Anssi: The closest thing related to this that comes to my mind is "canPlayType" in HTML5.
08:07:11 <mdadas_> mdadas_ has joined #webscreens
08:08:07 <tidoust> Schien: Privacy concern. If you know that Netflix is not supported in the user environment, could you use that information to display relevant ads?
08:08:45 <tidoust> Mark_Foltz: Tying apps to origins might be a way to mitigate the problem. Up to DIAL in that case.
08:09:39 <tidoust> Mark_Watson: Good statement for the security and privacy section. If you have a discovery mechanism that allows you to tell which URL are supported and which are not, there should be some scoping by origin.
08:09:40 <mh> q+
08:11:00 <tidoust> Mark_Foltz: The caveat that I would like to attach to this is that it really helps with DIAL. As soon as we have an HTML5 environment, this is kind of useless
08:11:18 <tidoust> Jean-Claude: Unless someone wants capability filtering
08:11:21 <tidoust> Mark_Foltz: Right.
08:12:50 <tidoust> Matt_Hammond: Instead of thinking it in terms of filtering, we could have it as a mechanism to hint on the specifics needed to support different mechanisms.
08:13:06 <tidoust> Mark_Foltz: The filtering would provide a better user experience.
08:13:33 <tidoust> Matt_Hammond: HTML5 as a fallback.
08:13:53 <tidoust> Mark_Watson: There may not be a compatible HTML5 fallback.
08:14:38 <anssik> q?
08:15:01 <mh> q-
08:15:27 <tidoust> Anssi: I'm hearing Mark_Watson willing to have a mechanism to have remote capability detection.
08:15:50 <tidoust> Mark_Watson: The whole capability detection issue is a large and distinct issue. This is more restricted.
08:16:02 <tidoust> ... Although the same solution could work in both cases.
08:17:32 <tidoust> ... The goal is to find a reasonable solution with a good balance between UX and privacy concerns.
08:18:10 <tidoust> Mark_Foltz: Another direction would be to allow a page to force local content rendering.
08:18:36 <anssik> q?
08:20:39 <tidoust> Mark_Foltz: In the end, we have a mechanism in place and need to investigate more the privacy implications.
08:21:06 <tidoust> [some discussion on the default presentation URL and the fact that it can be used to filter devices as well]
08:22:51 <tidoust> ACTION: Mark_Watson to look into privacy implications of filtering available screens according to the content being presented
08:27:37 <tidoust> PROPOSED RESOLUTION: For issue #9, include a URL parameter to "getAvailability" (subject to amendments to issue #81) and update security and privacy considerations section based on privacy investigation.
08:28:48 <tidoust> Topic: Screen availability mechanism for multiple session
08:29:00 <tidoust> -> https://github.com/w3c/presentation-api/issues/40 Issue #40
08:29:26 <anssik> scribe: anssik
08:29:58 <anssik> tidoust: if we want to support multiple screens, talking to multiple screen
08:30:57 <anssik> ... we don't know what happens to available boolean when you've already created the session
08:31:24 <anssik> ... and when you want to offer an app that can use three or four screen, it may prompt the user multiple times
08:31:36 <anssik> ... you may want to have only a single call that I may want to use multiple screens
08:31:48 <anssik> ... not sure if the spec should address it right now
08:31:56 <anssik> ... interested in two first points:
08:32:11 <anssik> ... 1) if I started a session, how do I know if there are still screens available
08:32:25 <anssik> whywhat: user can still take the same device and start a session
08:32:46 <anssik> schien: the best thing UA can do, on the trusted UA can show a flag of already user screens
08:33:11 <anssik> tidoust: not worries about that, more about how the web app knows can call startSesssion() again
08:33:27 <anssik> mfoltzgoogle: what is the use case? soccer game from two different angles
08:34:07 <anssik> ... maybe the UI is more like a "show me angle additional angle", should it be conditional to whether there are additional screens?
08:34:29 <anssik> ... adding an attribute to the AvailabilityListener for "are there unused screen available"
08:34:45 <anssik> ... our implementation has a definition of "unused screen"
08:35:13 <anssik> ... my questions: does this UC justify adding API surface to support this?
08:35:58 <anssik> tidoust: I think this might be a v2 feature
08:36:16 <anssik> ... making sure we can add it while keeping backwards compatibility with the v1 API
08:36:49 <anssik> mh: UA understands the sessions, their states
08:38:06 <anssik> mfoltzgoogle: could make it explicit in the screen picker UI
08:40:27 <anssik> markw: is there a UC for the web app to be able to say a certain screen cannot be reused, since the presentation is in progress, for example
08:41:27 <obeletski> q+
08:43:37 <whywhat> whywhat has joined #webscreens
08:43:42 <whywhat> q?
08:48:23 <obeletski> q-
08:53:31 <anssik> PROPOSED RESOLUTION: no change to the spec, we may want to provide informative guidelines to the implementors on the screen picker UI with regard to best practices for highlighting screens that are already used by other presentation sessions, clarify we do not support multiple screen selections from the screen picker UI
08:57:10 <tidoust> scribe: tidoust
08:57:11 <tidoust> Hongki: So, no multiple screen selections for this version of the Presentation API?
08:57:39 <tidoust> Francois: Right. If you feel strongly about this feature, the group needs concrete use cases that could be used to change the priorities.
08:57:56 <tidoust> Topic: Presentations from within nested browssing contexts
08:58:11 <tidoust> -> https://github.com/w3c/presentation-api/issues/79 Issue #79
08:58:19 <tidoust> scribe: obeletski
08:58:27 <tidoust> RRSAgent, draft minutes
08:58:27 <RRSAgent> I have made the request to generate http://www.w3.org/2015/05/20-webscreens-minutes.html tidoust
08:59:49 <anssik> q?
09:00:40 <schien> q+
09:01:10 <obeletski> Topic: Presentations from within nested browsing contexts #79 Issue -> https://github.com/w3c/presentation-api/issues/79
09:01:30 <anssik> s/Topic: Presentations from within nested browsing contexts #79 Issue -> https://github.com/w3c/presentation-api/issues/79//
09:02:00 <tidoust> s|Topic: Presentations from within nested browsing contexts #79 Issue -> https://github.com/w3c/presentation-api/issues/79/|
09:02:25 <tidoust> RRSAgent, draft minutes
09:02:25 <RRSAgent> I have made the request to generate http://www.w3.org/2015/05/20-webscreens-minutes.html tidoust
09:02:31 <obeletski> mfoltzgoogle: default presentation source and what is the information source for browser context
09:03:53 <tidoust> s|Topic: Presentations from within nested browsing contexts #79 Issue -> https://github.com/w3c/presentation-api/issues/79/|g
09:03:56 <tidoust> RRSAgent, draft minutes
09:03:56 <RRSAgent> I have made the request to generate http://www.w3.org/2015/05/20-webscreens-minutes.html tidoust
09:04:31 <tidoust> s|Topic: Presentations from within nested browsing contexts #79 Issue -> https://github.com/w3c/presentation-api/issues/79/||g
09:04:32 <tidoust> RRSAgent, draft minutes
09:04:32 <RRSAgent> I have made the request to generate http://www.w3.org/2015/05/20-webscreens-minutes.html tidoust
09:06:24 <obeletski> schien: providing a browser ui to initialize presentation creates confusion for the user in case of nested contexts
09:20:21 <hongki> q+
09:20:34 <anssik> ack schien
09:20:59 <anssik> ack hongki
09:21:10 <mdadas> mdadas has joined #webscreens
09:21:31 <obeletski> schien: in Firefox there is a sharing icon to mirror the whole tab to the other screen, for default presentation UI FF will start presentation for default URL. That way we redefine browser behaviour.
09:24:34 <obeletski> Hongki: would like to create use case for nested browser context
09:25:44 <whywhat> q+
09:26:47 <obeletski> Action: Hongki update use cases to incorporate  nested browser context issue
09:28:40 <obeletski> Action: Mfoltzgoogle Flush out behaviour of allow presentation attribute
09:30:59 <obeletski> PROPOSED RESOLUTON: Clarify how multiple levels of nesting behaves
09:34:16 <obeletski> PROPOSED RESOLUTION: define a new "allow-presentation" content attribute for the HTML iframe element that controls whether default-presentation, startSession(), joinSesssion() are functional; define failure path in the relevant algorithms when this attribute does not exist, clarify how multiple levels of nesting behaves
09:34:47 <anssik> s/allow-presentation/allowpresentation/
09:35:52 <whywhat> scribe: whywhat
09:36:02 <tidoust> Topic: Resumption of multiple sessions
09:36:10 <whywhat> TOPIC: Resumption of multiple sessions
09:36:32 <tidoust> -> https://github.com/w3c/presentation-api/issues/39 Issues #39
09:36:42 <whywhat> anssik: this is Francois proposal so please walk us through
09:37:26 <whywhat> tidoust: this is for the joinSession mechanism, what happens when you call startSession with the same url and id and if you can, what do you get when you call joinSession
09:37:50 <whywhat> ... we probably shouldn't allow starting another session with the same url and id
09:38:01 <whywhat> mfoltzgoogle: I second that
09:38:59 <whywhat> tidoust: what happens when I call startSession with the same url and id? e.g. if the user selects another screen, UA closes the running session or...
09:39:08 <whywhat> mfoltzgoogle: we could have it always fail
09:39:33 <whywhat> mfoltzgoogle: there's a use case to restart the terminated session which I'm okay with (the page recycles id)
09:40:38 <whywhat> ... the alternative is to behave like joinSession if user picks the same screen but if I pick another screen the current session stops
09:41:12 <whywhat> whywhat: we have it stated in the use cases
09:41:45 <whywhat> mfoltzgoogle: automatic termination may be a little tricky, we should probably require an explicit close() from the page
09:42:11 <whywhat> mh: why do we require the presentation id to be passed by the page?
09:42:54 <whywhat> anssik: IIRC it was proposed by Jonas Sicking so that the page could share the id between the controllers (e.g. a game)
09:43:52 <whywhat> mfoltzgoogle: yes. we could omit the presentation id and let other pages join the same presentation session just by URL
09:44:30 <whywhat> ... we could rely on the UA provided, hard to guess id and share it via local storage or cloud service to other pages
09:44:46 <anssik> RRSAgent, draft minutes
09:44:46 <RRSAgent> I have made the request to generate http://www.w3.org/2015/05/20-webscreens-minutes.html anssik
09:44:54 <whywhat> ... we could also append it to the url but it felt cleaner to keep it separate
09:45:37 <whywhat> tidoust: if we don't have a good use case, we should drop it from startSession
09:46:16 <whywhat> obeletski: joinSession - does it join the locally started session or some session started by another controller? it's still confusing
09:46:42 <whywhat> tidoust: we did discuss something yesterday during the discussion of issue #19
09:47:31 <whywhat> obeletski: we can join session or we can join presentation, we should be more clear on the terminology
09:48:15 <whywhat> mfoltzgoogle: agree, this is a different concept, if we want to change the behavior to call startSession to pick the existing presentation - it would join the presentation
09:49:12 <whywhat> tidoust: does the user have to kill presentation first if she wants to start a new one?
09:49:23 <mh> q+
09:49:31 <whywhat> mfoltzgoogle: yes, existing presentation will have to be closed explicitly
09:49:50 <whywhat> tidoust: do we still need presentation id for joinSession?
09:50:12 <whywhat> mfoltzgoogle: yes to avoid a random page/user connecting to the existing session without having to know the id
09:50:34 <whywhat> tidoust: then we have a malicious user / app problem to join the existing presentation
09:51:41 <whywhat> mfoltzgoogle: the presentation can't trust what's connected to it and adding an id would add a small security to it - the starter of the presentation would be trusted to share the id only to the right controllers
09:52:23 <whywhat> mh: I wonder how startSession that behaves joinSession map to HbbTV and DIAL? there's no guarantee that the right content is shown on the screen
09:52:49 <whywhat> tidoust: it seems like you can't implement joinSession (as in presentation) at all, no matter if you have the method or not
09:53:13 <whywhat> mfoltzgoogle: it depends on the presentation page whether to accept multiple connections, the spec should be clear
09:53:43 <whywhat> schien: q - we have three ways to receive a presentation session, we have two methods
09:54:24 <whywhat> ... can we have three methods?
09:54:42 <whywhat> all: startPresentation, joinPresentation, resumePresentation|Session
09:54:48 <mh> q-
09:55:17 <whywhat> mfoltzgoogle: hard to know what the user would pick - new screen or the one with the existing presentation
09:56:09 <whywhat> tidoust: we could show different screens for start and join
09:56:39 <whywhat> tidoust: we don't know if it's the first controller or not, so the page doesn't know what to call
09:56:42 <jcdufourd> jcdufourd has joined #webscreens
09:56:57 <jcdufourd> RRSAgent, draft minutes
09:56:57 <RRSAgent> I have made the request to generate http://www.w3.org/2015/05/20-webscreens-minutes.html jcdufourd
09:57:12 <whywhat> ... we perhaps should add a parameter to start session to specify if joining an existing presentation is okay or not
09:57:19 <whywhat> ... later
09:57:35 <whywhat> ... seems like the proposal is to remove id from startSession
09:58:01 <whywhat> mfoltzgoogle: we need a mechanism to join an existing presentation - either a new method or modify startSession
09:58:10 <whywhat> tidoust: it's probably related to issue #19
09:59:29 <hongki> hongki has joined #webscreens
10:02:18 <whywhat> tidoust: limit ids to the UA session, note that the ids might be shared between UAs so might need to be more unique
10:02:38 <whywhat> PROPOSED RESOLUTION: drop id from startSession() without strong use case, the UA generates the id
10:02:56 <mfoltzgoogle_> mfoltzgoogle_ has joined #webscreens
10:03:10 <tidoust_> tidoust_ has joined #webscreens
10:03:50 <tidoust_> RRSAgent, draft minutes
10:03:50 <RRSAgent> I have made the request to generate http://www.w3.org/2015/05/20-webscreens-minutes.html tidoust_
10:04:03 <whywhat_> whywhat_ has joined #webscreens
10:04:11 <whywhat_> scribe: whywhat_
10:04:26 <whywhat_> TOPIC: Allow page to designate a default presentation URL enhancement
10:05:06 <whywhat_> mfoltzgoogle: default presentation url gives a way to the UA to provide the best experience for the user if there's a default UI for presenting
10:05:46 <obeletski_> obeletski_ has joined #webscreens
10:06:10 <whywhat_> ... UA can also make the feature work more seamlessly if the user is streaming a tab and navigates to the presentation enabled page (e.g. navigated to YouTube - the UA starts the YT presentation)
10:07:27 <whywhat_> ... the other use case is voice action or a NFC tap or nearby proximity detection - present the url
10:07:42 <whywhat_> ... spec wise there's an implementation and spec changes in progress
10:08:02 <whywhat_> anssik: schien what do you think from the Firefox point of view?
10:08:39 <whywhat_> schien: not sure if the user would like to have the overridden behavior or the explicit behavior
10:09:14 <whywhat_> ... when I look at the default presentation url - developer needs to specify url in two places: the default one and the one for startSession
10:10:23 <whywhat_> ... if the page can create a session in advance and prevent default on the browser action - then the browser knows that the page has a specific way to handle the screen; if not, the browser can do its thing
10:11:11 <whywhat_> mfoltzgoogle: walking through a scenario - user initiates the presentation via UA button, the browser sends an event to the page and waits if it will be handled by the page
10:11:33 <whywhat_> schien: if the page handles the event, do nothing, if not, the UA defaults to tab casting
10:11:47 <whywhat_> schien: we can prevent specifying the default url for that
10:12:48 <anssik> RRSAgent, draft minutes
10:12:48 <RRSAgent> I have made the request to generate http://www.w3.org/2015/05/20-webscreens-minutes.html anssik
10:12:59 <whywhat_> mfoltzgoogle: how it would work from the implementation point of view? we would want to know if we need to start tab capturing or presenting the page's url
10:13:42 <whywhat_> schien: the page would call startSession from |defaultsessionstart| and the UA would show the picker
10:14:12 <whywhat_> mfoltzgoogle: setting up the UA would be hard beforehand if we need to wait for the page to do something
10:14:30 <whywhat_> ACTION: schien to write a proposed idl change for that
10:14:53 <whywhat_> schien: we seem to overload default presentation with many functionality
10:15:47 <whywhat_> mfoltzgoogle: I'd like both Firefox and Chrome to come up with a good solution but it shouldn't be mandatory for other UAs to implement if the UA doesn't support tab streaming
10:16:29 <whywhat_> PROPOSED RESOLUTION: review the two proposals and evaluate them against the use cases and requirements considering developers and implementors view points
10:18:07 <whywhat_> TOPIC: URL schemes supported in presentation API
10:18:34 <whywhat_> tidoust: what's the concern about limiting the schemes? Louay raised the issue but he's not here
10:19:21 <whywhat_> anssik: we should define which schemes must be supported and leave the rest undefined
10:19:28 <mdadas> mdadas has joined #webscreens
10:20:00 <whywhat_> mfoltzgoogle: for me the content type is more important, we certainly support html content but not clear about files/mp4/data urls/webapps etc
10:21:41 <whywhat_> PROPOSED RESOLUTION: do not restrict extensions that might want to make use of other URL schemes than http(s), however those alternative schemes are out of scope for v1
10:24:47 <whywhat_> anssik: we have three issues left that seem to be hard to resolve in 7 minutes we have left before lunch; after lunch we'll have the MWS event and the closing session
10:25:19 <anssik> TOPIC: Any Other Business
10:25:35 <whywhat_> tidoust: we discussed streamlined way to publish drafts of the Presentation API spec; the process can now be streamlined with an automatic tool
10:25:45 <anssik> http://www.w3.org/2014/08/pubworkflow.html
10:25:51 <whywhat_> ... I suggest we do it and want to make sure the group is fine with this approach
10:26:25 <whywhat_> anssik: it means the publications will happen when we did significant progress; I'll let Francois implement it for the group
10:26:34 <whywhat_> ... hear no concerns so let's do it
10:28:09 <whywhat_> ... thanks for your contributions and for participating in the event
10:28:48 <anssik> RRSAgent, draft minutes
10:28:48 <RRSAgent> I have made the request to generate http://www.w3.org/2015/05/20-webscreens-minutes.html anssik
10:28:51 <tidoust_> RRSAgent, draft minutes
10:28:51 <RRSAgent> I have made the request to generate http://www.w3.org/2015/05/20-webscreens-minutes.html tidoust_
12:26:10 <Zakim> Zakim has left #webscreens
14:57:59 <RRSAgent> RRSAgent has joined #webscreens
14:57:59 <RRSAgent> logging to http://www.w3.org/2015/05/20-webscreens-irc
14:58:10 <tidoust> RRSAgent, make logs public
14:58:18 <tidoust> RRSAgent, draft minutes
14:58:18 <RRSAgent> I have made the request to generate http://www.w3.org/2015/05/20-webscreens-minutes.html tidoust
14:58:48 <tidoust> Topic: Allow page to turn itself into a presentation session
14:58:58 <tidoust> -> https://github.com/w3c/presentation-api/issues/32 Issue #32
14:59:44 <tidoust> Summary of discussion during F2F wrap-up session: there may not be a need for a page to explicitly turn itself into a presentation session. The user agent could do that on its own (or asking for user permission first). The only part that may need to be adjusted to enable that use case is how the presenting page gets a pointer to the first session if it can be created after the page is loaded.
14:59:57 <tidoust> ACTION: @tidoust to investigate possible adjustments to the spec to allow a presenting page to detect when the first session is created in that case.
15:00:05 <tidoust> Also note that the page needs to run in private browsing mode for the user agent to be able to turn it into a presentation session.
15:00:16 <tidoust> i/Summary of discussion during/scribe: tidoust/
15:00:37 <tidoust> Topic: Presenting the content of an audio/video element
15:00:37 <anssik> RRSAgent, draft minutes
15:00:37 <RRSAgent> I have made the request to generate http://www.w3.org/2015/05/20-webscreens-minutes.html anssik
15:00:42 <tidoust> -> https://github.com/w3c/presentation-api/issues/13 Issue #13
15:01:15 <tidoust> Anton: [showing proposal on screen]
15:01:42 <hyojin> hyojin has joined #webscreens
15:02:14 <tidoust> ... Pretty similar to what we have in our Cast extension. The Cast button appears as a video player control button, allowing the video to be casted to a separate screen.
15:02:17 <anssik> http://avayvod.github.io/chrome-android-remote-playback.pdf
15:02:29 <obeletski> obeletski has joined #webscreens
15:03:06 <tidoust> Anton: It works well when the Web application does not use a custom UI for video playback.
15:03:37 <tidoust> ... There are no API for remote video playback
15:03:45 <tidoust> ... Also issues with subtitles and encrypted video.
15:04:50 <tidoust> ... Based on that, the proposal is an extension to the MediaElement to add a "remote" attribute that kind of emulates the Presentation API.
15:05:08 <tidoust> ... The object contains a "start" and "stop" method.
15:05:38 <tidoust> ... Also the <source> element should be extended to disallow remote playback.
15:06:35 <tidoust> Anssi: Is it something that you have implemented?
15:06:50 <tidoust> Anton: It can easily be implemented.
15:07:27 <tidoust> Anssi: I like the approach. The migration path is very simple for the developer too.
15:09:01 <tidoust> Francois: getAvailability filters potential devices based on the source URLs and media type?
15:09:03 <tidoust> Anton: right
15:10:51 <tidoust> Anssi: Does it make sense to have this evolve in a separate spec?
15:10:55 <tidoust> Anton: I think so.
15:12:26 <tidoust> Francois: One thing I wonder about is, once you've strated, all media features do not necessarily apply to the remote playback, depending on the underlying protocols being used.
15:13:06 <tidoust> Anton: Right.
15:13:39 <tidoust> Anssi: [showing Big Buck Bunny video to demo video content presentation]
15:16:44 <tidoust> ... +1 for the native implementation of that along the lines you suggest.
15:18:16 <tidoust> Matt_Hammond: The start and stop methods are not about starting/stopping the playback but rather about starting/stopping the session, right?
15:18:20 <tidoust> Anton: Yes.
15:19:32 <tidoust> Anton: to the question of unsupported features, the MediaElement already supports that to some extent. We should just ensure things are properly specified.
15:22:16 <tidoust> Anssi: This work is in scope by charter, and we can organize the split in specs the way we want so it's fine to move forward.
15:22:38 <tidoust> [Francois mumbling about pros and cons of having one spec or two specs]
15:24:50 <tidoust> ACTION: Anton to figure out a name for the spec and continue the work
15:25:26 <tidoust> ACTION: @tidoust to create the repo on GitHub for the spec once we have a name (and short name) for it.
15:25:33 <tidoust> Anssi: Could be Media Presentation API
15:25:56 <tidoust> Louay: I note that the same mechanism could be used for images.
15:28:16 <tidoust> Francois: For images, I would say the regular Presentation API is enough since you're just not going to need the communication channel and not going to connect to features provided by the ImgElement in HTML5 except to extract the source URL.
15:29:52 <tidoust> Anssi: for the dummy case, it could be just a hint on the image element that the user agent could use to propose to render the image on an UPnP Photo Renderer.
15:31:58 <tidoust> Jean-Claude: It could be done with a JS library, no need to have a standard attribute.
15:32:30 <tidoust> Anssi: You mean we could take an image and turn it into a video with one frame.
15:32:39 <tidoust> Francois: using "placeholder"
15:33:01 <tidoust> s/placeholder/poster/
15:33:15 <tidoust> Anssi: Exactly.
15:33:26 <anssik> http://www.w3.org/TR/html5/embedded-content-0.html#attr-video-poster
15:34:21 <tidoust> Francois: seems convoluted.
15:34:30 <tidoust> Anssi: right, could be used for prototyping.
15:36:25 <tidoust> [note that goal is to support constrained devices that can only render pictures, not videos]
15:37:50 <anssik> RRSAgent, draft minutes
15:37:50 <RRSAgent> I have made the request to generate http://www.w3.org/2015/05/20-webscreens-minutes.html anssik
15:40:24 <tidoust> Oleg: Wondering about the Web Audio API and chaining with the Presentation API. Also with the "sinkId" property that the Audio Output Devices API is defining.
15:40:55 <tidoust> Francois: good points, we will need to liaise with these groups and keep an eye on alignment.
15:42:05 <tidoust> ... So, in summary, we have a good starting point, and a few questions that will come back to bite us afterwards, that looks good!
15:42:27 <tidoust> Topic: Add facility for the opening page to add cloud paired screens as presentation targets
15:42:37 <tidoust> -> https://github.com/w3c/presentation-api/issues/61 Issue #61
15:43:34 <tidoust> Anssi: Last issue on our plate for this F2F.
15:43:48 <tidoust> RRSAgent, draft minutes
15:43:48 <RRSAgent> I have made the request to generate http://www.w3.org/2015/05/20-webscreens-minutes.html tidoust
15:44:44 <tidoust> Mark_Foltz: Basically, it would be a way to extend the way browser attaches to other screens by allowing pages to implement their own mechanism.
15:45:08 <tidoust> ... We would need to make sure that the UI picker is pretty clear that the user agent is not responsible for these screens.
15:45:54 <tidoust> ... Generally, from a practical point of view, on pre-DIAL TV platforms for instance, there is a way to control Youtube using out-of-band communications.
15:46:24 <tidoust> ... I don't have a specific mechanism proposed yet, but looking for feedback on the idea.
15:46:49 <tidoust> Louay: I can show a demo on this.
15:46:59 <tidoust> ... [showing demo]
15:48:08 <tidoust> ... Currently I propose a cast button that display a simple dialog to launch the application on a virtual display.
15:48:24 <tidoust> ... If the feature was there, this could be merged with other available displays.
15:48:47 <tidoust> ... It's pure JavaScript.
15:49:23 <tidoust> Anssi: I'm thinking, from the spec perspective, whether the spec should care about the presence of the proxy.
15:49:52 <tidoust> Mark_Watson: The browser does not care about the device but needs to show it in the list
15:50:42 <tidoust> Mark_Foltz: we need some way for the page to register these devices and then inform the page that one of them has been selected.
15:51:24 <tidoust> Mark_Watson: maybe we should change the name of the issue because "cloud-paired" seems to require some cloud-based solution that may not occur in practice.
15:52:13 <tidoust> Francois: so no integration with the Presentation API once the user has picked up the screen?
15:52:39 <tidoust> Mark_Foltz: Right, what is a weird is that the session would not behave the same way as other possible sessions.
15:53:06 <tidoust> ... I think it's a nice-to-have feature, not necessarily a must-have feature.
15:54:41 <anssik> RRSAgent, draft minutes
15:54:41 <RRSAgent> I have made the request to generate http://www.w3.org/2015/05/20-webscreens-minutes.html anssik
15:54:53 <tidoust_> tidoust_ has joined #webscreens
15:55:46 <tidoust_> scribe: tidoust_
15:56:06 <tidoust_> Anssi: summary is we could keep it as an open enhancement issue and revisit later on.
15:57:15 <tidoust_> Topic: Wrap-up
15:57:45 <tidoust_> RRSAgent, draft minutes
15:57:45 <RRSAgent> I have made the request to generate http://www.w3.org/2015/05/20-webscreens-minutes.html tidoust_
15:58:17 <tidoust_> Anssi: Thanks for participating. Sending my summary email right away. 10 days from now, proposed resolutions will become resolutions unless someone raises concerns before that.
15:58:29 <tidoust_> ... On to schnitzels!
16:00:44 <tidoust_> Anton: Two small points as feedback for the F2F. One is we did change the agenda a few times over the last couple of days. The second point is that it's hard to discuss API changes without being able to see concrete proposals.
16:01:11 <tidoust_> Anssi: True, maybe we can add something such as Etherpad or a Google doc.
16:01:22 <tidoust_> ... Very good idea, thanks for the feedback.
16:01:33 <tidoust_> [F2F adjourned]
16:01:41 <tidoust_> RRSAgent, draft minutes
16:01:41 <RRSAgent> I have made the request to generate http://www.w3.org/2015/05/20-webscreens-minutes.html tidoust_
17:44:31 <blassey> blassey has joined #webscreens