Re: Allow page to designate itself as presentation session

Hello everyone,

This thread reminds me of the discussions in Device APIs about a page exposing a service on the net.
The situation seems similar from the exposing perspective, but quite different from the discovering perspective.

François and Louay are right that something is needed on the exposing/display side.
Anton and Mark are right that the existing API covers cases on the “discovering”/control side.

On device 1, browser 1 has started page 1 which called startSession. Display 1 is discovered, then proposed to the user on device 1, then accepted, then connected to page 1.
On device 2, browser 2 starts page 2 which calls startSession. 
The question is then: should display 1 be discovered and proposed to user on device 2 ?
Maybe display 1 is a single user application. 
Maybe display 1 is a game with an option, sometimes single user, sometimes multi user.
Maybe display 1 is always multi-user.

Anyway, whether display 1 should be discovered and proposed to the second user is a choice of the application running on display 1. 
So having a function callable in the presentation application to define whether the application is to be proposed to other users is relevant.

If display 1 is single user and has indicated that it is not exposed, browser 2 does not propose it to the user on device 2.
If display 1 is multi user and has indicated that it is discoverable, browser 2 proposes it to the user on device 2.

From page 1 and page 2 perspective, nothing changed from the usual Presentation API exchange.
Browser 2 sees a difference, but does not share it with page 2.
The difference happens outside of the knowledge of the control side page.

The expose function to be called by the presentation application should at least have a boolean argument, meaning "I want/don’t want to be exposed”.
A case can be made to add a tag, which could signal “poker” meaning that the presentation application is currently running Louay’s poker game.
What do you think ?

I hope I am using the appropriate vocabulary.
Best regards
JC


> On 18 Nov 2014, at 09:29, Bassbouss, Louay <louay.bassbouss@fokus.fraunhofer.de> wrote:
> 
> 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 <http://w3c.github.io/presentation-api/#use-cases>
Jean-Claude DUFOURD
Directeur d’études / Multimedia Group / Telecom ParisTech
37-39 rue Dareau, 75014 Paris, France
Tél. : +33 1 45 81 77 33