Remove getAvailability() url argument unless implemented

[foolip]

This method was mentioned in https://lists.w3.org/Archives/Public/public-secondscreen/2015Jul/0002.html

The group notes that a generic true/false is not enough in many
situations where the URL to present may require additional capabilities.
That is the reason why the "getAvailability" function takes the URL to
present as parameter, to allow the user agent to filter screens.

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?

[avayvod]

There's an issue about adding this URL: #9

[foolip]

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.

[mwatson2]

A special URL format is presently the only way we can integrate with DIAL
apps, for example. If the page is capable of communicating with a remote
DIAL app (for example www.netflix.com communicating with a Netflix DIAL
application on a TV) and the UA supports DIAL the page needs some way to
tell the UA to filter screens to only those with the requested DIAL app.

We could make this a first-class API feature, for example with 'Discovery
protocol' and 'Discovery application name' fields, but so far people have
preferred to leave it as something to be encoded in the URL.

...Mark

Sent from my iPhone

On Jul 7, 2015, at 6:56 AM, Philip Jägenstedt notifications@github.com
wrote:

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.

—
Reply to this email directly or view it on GitHub
#138 (comment).

[foolip]

What does that special URL format look like?

[mwatson2]

That depends on the discovery protocol. For DIAL it was suggested to use
the fragment portion of the URL and including two fields in the usual query
string format, dialAppName and dialPostData, but this would be in
scope of the specification that defines DIAL <-> Presentation API
integration not in scope of the Presentation API itself.

...Mark

Sent from my iPhone

On Jul 7, 2015, at 7:21 AM, Philip Jägenstedt notifications@github.com
wrote:

What does that special URL format look like?

—
Reply to this email directly or view it on GitHub
#138 (comment).

[foolip]

It sounds like this is all still a bit speculative at this point, or is there a concrete plan to do something with the url argument in the near future in some implementation? @avayvod?

[mfoltzgoogle]

The URL argument to getAvailability isn't used at present in Blink because it's a relatively recent spec change that isn't yet plumbed through into Chromium. The functionality is already present through a much more roundabout mechanism: the document can set a default presentation URL [1] which in turn conditionally fires an available event on Presentation if there is a matching display.

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 PresentationRequest which combines display availability and session creation, currently discussed in #26. This would move the URL parameter from getAvailability to the PresentationRequest ctor.

Once consensus is reached on #26 we will complete the implementation in Blink and Chromium.

Does that answer your concerns @foolip?

[1] https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/web/WebDocument.cpp&rcl=1436211521&l=370

[foolip]

What I'm curious to know is what "matching display" means, i.e. will be any observable difference based on the argument passed?

[mfoltzgoogle]

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

[foolip]

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 url argument actually be used, or will it be a placeholder that ends up in a TODO somewhere? If it is used, how?

[mfoltzgoogle]

The answer to that question lies in the trajectory of #26. Either it will remain in the getAvailability API and will be implemented here or it will move to PresentationRequest.

[foolip]

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 url argument is actually used, or if it's defined to parse some kind of microsyntax from the URL, that seems like a less than ideal interface. Something more explicit like MediaStreamConstraints for getUserMedia() could make sense.