Re: Allow page to designate itself as presentation session

Hey Everyone,

First, regarding the question about family games on Chromecast, I can
comment on this.  As the public Google Cast SDKs show, the communication
model in Cast has always always for multiple senders to be connected in
parallel to a single receiver.  Cast semantics define that if the user
chooses to present to a target, and it's already running the requested app
ID, then the running session can be joined.

The Presentation API (around manually joining an existing session in
particular, but also around programmatically joining a session by ID) is
essentially equivalent to this, except we match on presentationUrl +
presentationId.

To Jean-Claude's original question, I feel the presentationId semantics
already cover much of what's necessary - quite intentionally:

   - To create a single-player only session that can never be joined,
   supply a random presentationId when starting the session.  The UA that
   created the session can rejoin it later (e.g. remember via local storage),
   but nobody else can.


   - To create a limited multiplayer game (e.g. where I invite you),
   generate a presentationId on the server, and distribute it to clients.  The
   semantics already defined in 5.1 and 5.2 now allow manual or automatic
   connection, but only by those invited to the game.


   - To create an open multiplayer game, omit the presentationId.  Anyone
   can now join the session as long as the presentationUrl matches.

The main gap necessary to allow multiple simultaneous senders is on the
messaging side; the sender side doesn't change much, but the presentation
session needs to differentiate between senders (can be done at the app
level), and needs to be able to send messages back to all senders (ideally,
individually, though broadcast could work with app-level filtering).

We'd have to decide if we want this to be in scope, but as the gaming
example shows, it is actually useful to support this.

Mark.

On Fri, Nov 21, 2014 at 4:33 AM, Bassbouss, Louay <
louay.bassbouss@fokus.fraunhofer.de> wrote:

> Hi Anssi,
>
> Agree from my side.
>
> Louay
>
> > -----Original Message-----
> > From: Kostiainen, Anssi [mailto:anssi.kostiainen@intel.com]
> > Sent: Freitag, 21. November 2014 13:13
> > To: Bassbouss, Louay
> > Cc: Rottsches, Dominik; Francois Daoust; Anton Vayvod; public-
> > secondscreen@w3.org; public-webscreens@w3.org; mark a. foltz
> > Subject: Re: Allow page to designate itself as presentation session
> >
> > Hi Louay, All,
> >
> > > On 21 Nov 2014, at 13:54, Bassbouss, Louay
> > <louay.bassbouss@fokus.fraunhofer.de> wrote:
> >
> > [...]
> >
> > >> So, the scenario you’re describing could be implemented as follows:
> > >> One local player is responsible for pushing the poker table to the
> > >> big screen. Once that player leaves the game and disconnects from the
> > >> display, the presentation session id is transferred to another
> > >> remaining player via the game server who then resumes the presentation
> > session.
> > >>
> > > Thx for feedback. I was thinking about using Presentation API for
> realizing
> > offline multi-user applications (most relevant examples are Multiplayer
> > games)  without the need to write code for the server side (only for
> serving
> > the html files). It will make the development of these kind of
> applications
> > much easier. What do you think about this flow to implementing the Poker
> > example using presentation API?
> >
> > Louay - I think the offline use case -- while very interesting -- may
> not be of
> > the highest priority for the group considering the scope we agreed on at
> > chartering time.
> >
> > To that end, and based on what Dominik described above, it seems we may
> > want revisit issue #27 [1] once we've first ironed out the aspects of
> the API
> > that address the most common use cases for which we have an agreement
> > on. Also, it would be helpful to experiment in code first with this
> particular
> > use case.
> >
> > Louay - does that sounds reasonable?
> >
> > All - please let us know if you have any concerns.
> >
> > Thanks,
> >
> > -Anssi
> >
> > [1] https://github.com/w3c/presentation-api/issues/27
>