W3C home > Mailing lists > Public > public-secondscreen@w3.org > November 2014

Re: Multiple controlling pages (Was: Re: Allow page to designate itself as presentation session)

From: Anton Vayvod <avayvod@google.com>
Date: Thu, 27 Nov 2014 17:04:36 +0000
Message-ID: <CAOjek6qWRzzgp0hh+9QR2_Mbg_hb_dMSR3wdDxvsDnmXeeNr8w@mail.gmail.com>
To: Francois Daoust <fd@w3.org>
Cc: Mark Scott <markdavidscott@google.com>, "Bassbouss, Louay" <louay.bassbouss@fokus.fraunhofer.de>, "Kostiainen, Anssi" <anssi.kostiainen@intel.com>, "Rottsches, Dominik" <dominik.rottsches@intel.com>, "public-secondscreen@w3.org" <public-secondscreen@w3.org>, "public-webscreens@w3.org" <public-webscreens@w3.org>, "mark a. foltz" <mfoltz@google.com>
Hi Francois,

thanks for splitting this issue out of the other thread!

If we consider each client as a separate session, would something like
'onconnected' event listener work instead of the
navigator.presentation.session? E.g.:

// presentation page

function onclientstatelistener(session, state) {
  // handle the state change for the particular client (although having
onconnected makes it half redundant since the UA still sends 'connected'
state change)

function onclientmessage(session, message) {
  // hangle the message from a particular client

// state visible to all clients, i.e. poker table
var myGlobalState = { ... };
// per-client states, i.e. cards for each player; also a session for each
var myClientState = [];

navigator.presentation.onconnected = function(e) {
  // setup the new session to get updates from it
  var clientState = newClientState(e.session);
  var session = clientState.session;
  session.onstatechange = onclientstatelistener.bind(null, session);
  session.onmessage = onclientmessage.bind(null, session);

  // update the global state and add a new client state

  // share the global state and the new client state

// broadcast when the global state of the presentation changes
for (var i = 0; i < myClientSessions.length; ++i) {

// state of one client changes

We can remove navigator.presentation.session from the spec then and
consider the presentation page ready once it sets the
navigator.presentation.onconnected listener.
We could also add navigator.presentation.ondisconnected and such (if we
have more states for sessions) and remove onstatechange from the session?
The same events could be used in the same manner for the presenting page as
well although it would change the spec even more.



On Thu, Nov 27, 2014 at 1:19 PM, Francois Daoust <fd@w3.org> wrote:

> On 2014-11-26 04:05, Mark Scott wrote:
> [...]
>> 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).
> Being able to send a private message to a particular sender sounds
> important. Sticking to the Poker example, the Poker table screen would want
> to distribute cards to each sender individually. Cheating would be easy
> (e.g. through custom scripts à la Greasemonkey) if players received the
> whole distribution.
> A broadcast message can easily be emulated with a simple "for" loop and I
> don't think there are many network optimizations that a browser could do to
> implement it differently. Or is there?
>> 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.
> I note that the possibility to have multiple controlling pages is in scope
> of the working group per charter [1]:
> "pages hosted by other user agents may be authorized to control the
> remotely rendered content *at the same time*."
> Actually, that was one of the requests for clarification received during
> the internal charter review.
> Whatever the solution, it is going to impact how these sessions are
> exposed to receivers since "navigator.presentation.session" is a
> singleton right now. It might be good to handle the possibility for
> receivers to have multiple senders as soon as possible.
> Francois.
Received on Thursday, 27 November 2014 17:05:26 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:18:43 UTC