Re: Updated Presentation API WebIDL - call for review

On Tue, Mar 11, 2014 at 6:21 PM, Rottsches, Dominik <
dominik.rottsches@intel.com> wrote:

> 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?
>

Hmm, I thought this was clear in the Flinging use-case. If the second
screen that is discovered is running a Netflix application and is
discovered over DIAL, it will only play www.netflix.com URLs. The DIAL
agent in the UA will know this (if it supports DIAL it will know the
various registered DIAL applications).


>
> > 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 should be controlled by the site. I am thinking of how this would work
on a laptop, say. There is a lot of screen real-estate and you might not
want this dialog / drop-down to appear at some place totally disconnected
from where you click (not least to reduce how far you need to move the
mouse).


>
> > 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.


So, then, this is going to result in devices being shown that can't, in
fact, render the URL the site wants to render. That doesn't seem right.


> 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?
>

I would say that if the site has indicated a clear intent - play this,
then play that instead - we should follow the site's instructions. 

...Mark



>
> Regards,
>
> Dominik
>