RE: Updated Presentation API WebIDL - call for review

Hi Mark,

Thanks for your feedback - let me try to address the points you're raising:

> The first thing that should happen, then, is that the site informs the UA of the URL(s) it might wish to present. This tells the UA to start the discovery processes (if not always running) and what kind of URL support to look for. For example, if the site wants to show content from www.netflix.com and all that can be found through the various discovery mechanisms is a www.youtube.com application advertised over DIAL, then there are no screens available that the site can use and the icon should not be shown at all.

The first step, the discovery process, begins when the page first subscribes to the onavailablechange event, that would be the trigger. The discovery process, as we describe it in the proposal is independent of the URL that's later specified in the requestSession call. 

> With the API as documented, though, IIUC, the first thing that happens is that the site gets the onavailablechange event. How can the browser generate this without knowing the URL ?

The browser can generate the onavailblechange event because we so far did not design any by-URL restrictions for the discovery. The secondary screen would be generally flexible to load any URL since it's a general purpose UA. Could you perhaps elaborate in which situation, or especially for which of the use cases we'd need the URL during the discovery stage?

> Second, the site ought to be able to cause the UA-managed selection list to appear at a position of its choice, for example close to the icon that triggered the list to be shown.

I'd say if the dialog for screen selection immediately appears when clicking we don't necessarily need a spatial connection? But if participants of the group feel strongly about this, we may add this to the specification. I would argue we may not want to spec where such a dialog appears to allow more flexibility of implementation on mobile devices?

> It seems also that if there are multiple second-screen buttons then a URL is needed for each and the device list may be different for each. This would suggest to me that the availablechange event should be on the PresentationSession, which then means that much more than one bit of information is being revealed to the site.

Similar to above: The availability would be independent of the URLs. You could have multiple buttons, each resulting in a different requestSession() call with different URLs specified. What we may want to specifiy: If the user clicks on two such buttons in sequence while there's only one physical screen: Should the second button click take over the screen that's already used or should that requestSession call receive an error? 

Regards,

Dominik

Received on Wednesday, 12 March 2014 01:22:06 UTC