RE: Allow page to designate itself as presentation session

CIL

> -----Original Message-----
> From: Kostiainen, Anssi [mailto:anssi.kostiainen@intel.com]
> Sent: Montag, 17. November 2014 16:18
> To: Francois Daoust; Bassbouss, Louay; Anton Vayvod
> Cc: public-secondscreen@w3.org; public-webscreens@w3.org
> Subject: Re: Allow page to designate itself as presentation session
> 
> Hi All,
> 
> > On 12 Nov 2014, at 19:16, Francois Daoust <fd@w3.org> wrote:
> 
> [...]
> 
> > In essence, once we add the possibility to join an existing session or
> resume a connection to a running presentation session through a call to
> "joinSession", it seems natural to add some way for a page to advertise itself
> as a running presentation session, to avoid having to call "startSession"
> altogether.
> >
> > A typical use case:
> > "A user starts an application on her Smart TV that displays family pictures
> and videos in the background. While the application runs, her child opens the
> application on his tablet, joins the running presentation application on the
> Smart TV and adds pictures and comments to the slideshow."
> 
> It appears a similar use cases have been discussed earlier, for example the
> multiplayer gaming on a TV suggested by Jonas [1].

[Louay] Yes I remember we discussed multiplayer gaming on TV but it seems it is not covered in the Use Cases section [1]. I will create new issue on github and make a proposal for a multiplayer UC (Poker). 
> 
> Are we able to enumerate the generic requirements for this type of use
> cases?
[Louay] 
> 
> > The Presentation API enables the above scenario... provided the user
> starts the Smart TV application from another device in the first place. Said
> differently, the Presentation API enables more complex scenarios (Smart TV
> + controlling device) to create sessions, which is good, but not the more
> simple one (Smart TV only), which seems a bit awkward.
> >
> > Or perhaps this could actually already be handled at the UA level: if the UA
> detects code in a Web app that e.g. listens to presentation session
> connections, it could perhaps offer an option on the UA's user interface to
> start the session directly (with a choice that says "and do that automatically
> next time the app starts").
> 
> Anton's response [2] seems to suggest no normative changes are needed to
> the API on the sender side. Correct?
[Louay] I think no changes are needed

> 
> Do we yet have an understanding of the changes (if any) required to the API
> exposed to the receiver side?
[Louay] If we want to give the web page controls over making the session discoverable or not, then we need to extend the API. 
More important is communication: if we allow multiple connections to the receiver page, what is the semantic of session.postMessage(msg) on the receiver page? It is broadcast to all senders? If yes do we need unicast channels for each sender?

> 
> Also, I'd like to understand whether we could leave this up to the
> implementation (i.e. "handle at the UA level") and still expect users to figure
> it out regardless of the UI/UX differences?
> 

[1] http://w3c.github.io/presentation-api/#use-cases

Received on Tuesday, 18 November 2014 08:29:57 UTC