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

Re: GH issue #27: Define a Multiplayer Gaming Use Case

From: Bassbouss, Louay <louay.bassbouss@fokus.fraunhofer.de>
Date: Sat, 22 Nov 2014 07:57:46 +0000
To: "mark a. foltz" <mfoltz@google.com>
CC: "Kostiainen, Anssi" <anssi.kostiainen@intel.com>, "public-webscreens@w3.org" <public-webscreens@w3.org>, "public-secondscreen@w3.org" <public-secondscreen@w3.org>
Message-ID: <68B274CC-963A-4C89-B3F3-E5842CC338DF@fokus.fraunhofer.de>

Hi Mark,

On 21.11.2014, at 23:35, "mark a. foltz" <mfoltz@google.com<mailto:mfoltz@google.com>> wrote:

Ansii, Louay,

- I agree that mesh (n:n) communication would complicate the spec.  Mesh communication could be better served by a separate web service that each presentation participant connects to, distinct from the communication channel offered by the spec.

- The scenario for 1:n communication between the presenting and controlling pages should be fleshed out.  There could be an explicit API to send a broadcast message, or we provide N different MessagePort-like objects that the presenting page could use to message to all or a subset of controlling pages.

Should the 1:n requirement be captured in a separate GH issue?

Yes let us file new issue for this req. maybe with the same priority as for issue #27?

On Tue, Nov 18, 2014 at 7:23 AM, Kostiainen, Anssi <anssi.kostiainen@intel.com<mailto:anssi.kostiainen@intel.com>> wrote:
> On 18 Nov 2014, at 17:02, Bassbouss, Louay <louay.bassbouss@fokus.fraunhofer.de<mailto: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.



Received on Saturday, 22 November 2014 07:58:23 UTC

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