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

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

From: mark a. foltz <mfoltz@google.com>
Date: Fri, 21 Nov 2014 14:34:24 -0800
Message-ID: <CALgg+HEcrEJveS-vt-tuo6AO_PTXJEC==rZptZWaqOonZuGK5w@mail.gmail.com>
To: "Kostiainen, Anssi" <anssi.kostiainen@intel.com>
Cc: "Bassbouss, Louay" <louay.bassbouss@fokus.fraunhofer.de>, "public-webscreens@w3.org" <public-webscreens@w3.org>, "public-secondscreen@w3.org" <public-secondscreen@w3.org>
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?

m.



On Tue, Nov 18, 2014 at 7:23 AM, Kostiainen, Anssi <
anssi.kostiainen@intel.com> wrote:

> > 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 Friday, 21 November 2014 22:35:12 UTC

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