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

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

From: Francois Daoust <fd@w3.org>
Date: Thu, 27 Nov 2014 14:19:51 +0100
Message-ID: <547724F7.60406@w3.org>
To: Mark Scott <markdavidscott@google.com>, "Bassbouss, Louay" <louay.bassbouss@fokus.fraunhofer.de>
CC: "Kostiainen, Anssi" <anssi.kostiainen@intel.com>, "Rottsches, Dominik" <dominik.rottsches@intel.com>, Anton Vayvod <avayvod@google.com>, "public-secondscreen@w3.org" <public-secondscreen@w3.org>, "public-webscreens@w3.org" <public-webscreens@w3.org>, "mark a. foltz" <mfoltz@google.com>
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.

Received on Thursday, 27 November 2014 13:20:30 UTC

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