-
Notifications
You must be signed in to change notification settings - Fork 39
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remove getAvailability() url argument unless implemented #138
Comments
There's an issue about adding this URL: #9 |
Thanks, Anton! Is there something sensible that could be implemented around this? Putting a microsyntax in the URL or requiring the resource to be fetched and analyzed both seem like slightly odd APIs for detecting support for device capabilities. |
A special URL format is presently the only way we can integrate with DIAL We could make this a first-class API feature, for example with 'Discovery ...Mark Sent from my iPhone On Jul 7, 2015, at 6:56 AM, Philip Jägenstedt notifications@github.com Thanks, Anton! Is there something sensible that could be implemented around — |
What does that special URL format look like? |
That depends on the discovery protocol. For DIAL it was suggested to use ...Mark Sent from my iPhone On Jul 7, 2015, at 7:21 AM, Philip Jägenstedt notifications@github.com What does that special URL format look like? — |
It sounds like this is all still a bit speculative at this point, or is there a concrete plan to do something with the |
The URL argument to Mozilla had some objections to overloading the semantics of the default presentation in this way, and we are in the process of revising the spec to cleanly define a Once consensus is reached on #26 we will complete the implementation in Blink and Chromium. Does that answer your concerns @foolip? |
What I'm curious to know is what "matching display" means, i.e. will be any observable difference based on the argument passed? |
The specific circumstance is when the only display available is incapable of rendering generic Web content (i.e. usable in 2-UA mode) or a generic video stream (i.e. usable in 1-UA mode). However, it can function as a proxy by mapping a URL resource to a fixed set of presentation modes. This is the case that mwatson2@ alluded to in #138 (comment) for Netflix. As it happens, this is a common case for users who have Internet-connected TVs, set top boxes, game consoles, etc. most of which use DIAL [1] to facilitate remote launch of these applications. Rather than offering the user these displays as generic presentation targets but having them fail to render in many circumstances, this allows the UA to offer presentation when it has some confidence that the request will succeed (by first querying the device for compatibility with the DIAL application). If you are curious about the specific mechanism see section 6.1 of the specification [1]. Over time I hope that this is the less common case. Cast devices will all support 1-UA mode initially and there is an active effort to add Presentation API support to HBB TV 2.0 in 2-UA mode #67 (comment). Down the road we've discussed expanding the Presentation API to allow the controlling page to require more specific capabilities from the display like specific codecs, audio/video outputs, or perhaps installed applications. But we don't have a specific proposal yet that encompasses all these cases. [1] http://www.dial-multiscreen.org/dial-protocol-specification |
Thanks for expanding on that, @mfoltzgoogle, not offering to use devices which will not work indeed sounds very important. Perhaps this is better discussed on blink-dev, but what I'm getting at is this: When the Presentation API ships in Chromium/Blink, will the |
The answer to that question lies in the trajectory of #26. Either it will remain in the |
OK, so it sounds like this is all a bit up in the air still, feel free to close this issue if you think there is no problem. What I will say is that if in the end it's completely undefined (by any spec) how the |
This method was mentioned in https://lists.w3.org/Archives/Public/public-secondscreen/2015Jul/0002.html
As actually implemented in Blink, the method takes an argument but it's never used. Unless there is an implementation that intends to do something with the argument, it would be better to not have it. Otherwise there will be no way to feature detect when it's actually supported, as
Presentation.prototype.getAvailability.length
will already be 1.Slightly off-topic, it's not clear to me what could actually be done with just a URL. Presumably one would have to actually try to load the URL, make a guess about what features it needs to render, and then match that against the capabilities of the platform?
The text was updated successfully, but these errors were encountered: