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

Hi Anssi, All,

> -----Original Message-----
> From: Kostiainen, Anssi [mailto:anssi.kostiainen@intel.com]
> Sent: Dienstag, 18. November 2014 15:48
> To: Bassbouss, Louay
> Cc: public-webscreens@w3.org; public-secondscreen@w3.org
> Subject: Re: GH issue #27: Define a Multiplayer Gaming Use Case
> 
> Hi All,
> 
> > On 18 Nov 2014, at 11:52, Bassbouss, Louay
> <louay.bassbouss@fokus.fraunhofer.de> wrote:
> >
> > Dear All,
> >
> > I just filed a new GH issue #27  “Define a Multiplayer Gaming Use Case” [1]
> to derive new requirements (if any) for Presentation API. In the description
> of the issue I putted a proposal for a Poker Use Case.
> 
> Louay - thanks for the illustrated use case.
> 
> All - let's derive the concrete requirements from this UC.
> 
> To start, #19 [2] notes the following re similar use case:
> 
> * Firing of onstatechange = "connected"/"disconnected" on both sides
> * Semantics of close() on both sides
> 
> Is it is up to the presenting page to proxy this information (state change) to
> the other controlling pages as needed?
> 
> 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. 

> WDYT?
> 
> Thanks,
> 
> -Anssi
> 
> > [1] https://github.com/w3c/presentation-api/issues/27

> 
> [2] https://github.com/w3c/presentation-api/issues/19

> [3] https://html.spec.whatwg.org/multipage/comms.html#broadcastchannel


Thanks, 
Louay

Received on Tuesday, 18 November 2014 15:03:23 UTC