- From: Kostiainen, Anssi <anssi.kostiainen@intel.com>
- Date: Tue, 18 Nov 2014 15:23:37 +0000
- To: "Bassbouss, Louay" <louay.bassbouss@fokus.fraunhofer.de>
- CC: "public-webscreens@w3.org" <public-webscreens@w3.org>, "public-secondscreen@w3.org" <public-secondscreen@w3.org>
> On 18 Nov 2014, at 17:02, Bassbouss, Louay <louay.bassbouss@fokus.fraunhofer.de> wrote: > >> Can we assume the controlling pages do not know of each other and the >> state changes as well as messaging between the controlling pages must be >> proxies through the presenting page (or some other means defined by other >> specs)? > [Louay] I share the same opinion. I think 1:n communication (1 is presenting page and n for controller pages) is enough at this stage. n:n mesh communication will make the spec and implementation more complex. But If we find use cases where this kind of communication is required, we need to consider the n:n case. Currently I don’t have a use case in mind. The generic n:n comms problem on the Web has not been addressed yet, and the still experimental BroadcastChannel only proposes a solution to same origin pages opened by the same user agent. Thus it seems reasonable for the group to scope this API to 1:n communication (All - if you have concerns, please let us know). Now, we'd need to tease out the requirements for the 1:n comms after which we can start to look at concrete spec changes. Thanks, -Anssi
Received on Tuesday, 18 November 2014 15:24:14 UTC