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

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
client
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
  myClientState.push(clientState);

  // share the global state and the new client state
  session.postMessage(myGlobalState);
  session.postMessage(clientState);
};

....
// broadcast when the global state of the presentation changes
for (var i = 0; i < myClientSessions.length; ++i) {
  myClientState[i].session.postMessage(myGlobalState);
}

// state of one client changes
clientState.session.postMessage(clientState);


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.

WDYT?

Anton.


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