Re: New Proposal now up for Discussion on the Wiki

On Thu, Feb 6, 2014 at 11:20 AM, Rottsches, Dominik <
dominik.rottsches@intel.com> wrote:

> Hi Anton, Louay,
>
> On 06 Feb 2014, at 12:38, Anton Vayvod <avayvod@google.com<mailto:
> avayvod@google.com>> wrote:
>
> as shown here: http://roettsch.es/player_target_list.png
>
> This server requires a login when I click on the link. However, I think I
> understand what you mean and thanks for reminding of this important use
> case.
>
> Apologies, this should work now.
>
> On 06 Feb 2014, at 12:38, Anton Vayvod <avayvod@google.com<mailto:
> avayvod@google.com>> wrote:
>
>
> In this case the YouTube page is aware of the available presentation
> devices and shows them using its own styling and UI. For this to be
> possible via Presentation API, enumeration with human readable names would
> be required.
>
> I think we could go the other way: allow the site to provide additional
> items to the selection list. So YouTube would add a list of its own device
> ids for these manually paired devices. I believe this is what the new Cast
> Web SDK does.
>
> Just to clarify: You mean, allowing the page to add items to the selection
> dialog that the UA shows?
> Would you have a reference or example for how this is done in the Cast Web
> SDK?
>
> Could you perhaps elaborate a bit more how you’d see this working. I am
> skeptical this works generically while still providing a logical and
> consistent Presentation API which would not break custom casting
> implementations like the one we see here, Youtube pairing.
>
> Imagine: The page calls requestSession() or present() or a similarly named
> function, and has previously called something like
> addFlingMenuEntry(“CustomPairingTarget”). How would you handle the result
> if for the custom server-side pairing implementation you just need to have
> the “CustomPairingTarget” name returned and then do proprietary
> communication with the server in order to control the remote instance.
>

The result of requestSession is an object that describes the session and
selected device. So the site that provided custom device ids/names would
have to check if the selected device was one of the custom ones and proceed
with the proprietary route of establishing the channel of communication.
The UA would not provide a MessagePort or anything else in the result
bundle. If the device name is different from the ones supplied by the
website, it would use the MessagePort and other properties provided by the
UA.


>
> There’s something to say about both approaches. The page author saves some
> time by not having to provide a selection mechanism. On the other hand I’d
> still say it gives the page more flexibility if it can use the human
> readable names for its own selection mechanism.
>
> Louay, Fraunhofer raised a github issue on supporting multiple screens -
> maybe you could elaborate a bit on the use cases you had in mind?
>
> Dominik
>
>