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

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
>