Re: New Proposal now up for Discussion on the Wiki

Hi Dominik,

comments inline.

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

> Hi Anton, other participants,
>
> thanks for the detailed review of the proposal and your comments.
>
> On 05 Feb 2014, at 18:09, Anton Vayvod <avayvod@google.com> wrote:
>
> > I've just left some comments on the Wiki page, mostly in regards to the
> device selection. I also tried to answer most of the open questions.
>
> From your comments on the wiki I understand, in your opinion device
> selection should be on the UI side. I took at your link to the Chromecast
> API where the device selection is left to the Cast extension.
>
> We went through one example which lead us to think enumeration might
> actually be important:
>
> The use case we were considering is the ability of the Youtube website to
> cast/fling to a couple of nearby devices, via different connection
> methodologies, Chromecast or YouTube’s proprietary pairing.
>
> If you connect a “controller" page to a YouTube page in TV mode [1], the
> paired targets show up in a UI selection, along with the name of the
> available Chromecast, 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.


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


> If we only had the option to show here an entry called “Other Presentation
> Devices” for example, then this entry could be selected and then a separate
> UA user interface would appear for a second-level screen selection. But IMO
> this would make the user experience much less consistent. Hence we thought
> enumeration is useful and important.
>
> It’d be interesting to hear your thoughts.
>
> Dominik
>
>
> [1] By going to youtube.com/pair on the controller side and youtube.com/tv(and then navigate to Settings->Pair), and type in the pairing id on the
> controller side, then watch any video and observe the cast button showing
> up, listing the paired players.
>
>
> > Could you also add the open question about restricting the navigation on
> the second screen? I now think we should be fine without any restrictions.
> >
> > On Fri, Jan 31, 2014 at 10:56 AM, Rottsches, Dominik <
> dominik.rottsches@intel.com> wrote:
> > Dear members of the webscreens CG,
> >
> > in the interest of easier discussion and collaboration we have now moved
> and merged the ideas on how to evolve the API to a Wiki page:
> >
> >  https://www.w3.org/community/webscreens/wiki/API_Discussion
> >
> > On this page, we documented existing and a new proposed use case "Media
> Flinging to Multiple Screens", derived requirements from them. Then we
> documented one proposal how to address the requirements to facilitate the
> discussion.
> >
> > There are open questions and your input is needed in how we should
> tackle those.
> >
> > We encourage everyone to have a look at this unified proposal, evaluate
> it and take part in the discussion. For example by raising questions on the
> mailing list or commenting directly in the Wiki using indentation and
> Wiki-style signatures (Wikimedia Syntax: [~~~~]).
> >
> > As the next step, once we reach a level of consensus, we can take the
> concepts from this page and incorporate them into our Presentation API
> specification draft.
> >
> > Dominik
> >
>
>