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

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

From: mark a. foltz <mfoltz@google.com>
Date: Mon, 29 Dec 2014 13:19:00 -0800
Message-ID: <CALgg+HHPJ_3dBDfwoKuGyrRnnDZ9Hpc6s_7yJcmHqR4UeOagtw@mail.gmail.com>
To: "Bassbouss, Louay" <louay.bassbouss@fokus.fraunhofer.de>
Cc: "Kostiainen, Anssi" <anssi.kostiainen@intel.com>, "public-webscreens@w3.org" <public-webscreens@w3.org>, "public-secondscreen@w3.org" <public-secondscreen@w3.org>
On Fri, Nov 21, 2014 at 11:57 PM, Bassbouss, Louay <
louay.bassbouss@fokus.fraunhofer.de> wrote:

>
> Hi Mark,
>
> On 21.11.2014, at 23:35, "mark a. foltz" <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?
>


I filed https://github.com/w3c/presentation-api/issues/36 to cover this
case.  It appears I don't have privileges to assign labels to issues, so if
you would like to mark it P3 go ahead.

Cheers,
Mark



>
>   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
>
>
>   Thanks,
> Louay
>
Received on Monday, 29 December 2014 21:19:48 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:39:46 UTC