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

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

From: Kostiainen, Anssi <anssi.kostiainen@intel.com>
Date: Tue, 18 Nov 2014 14:47:56 +0000
To: "Bassbouss, Louay" <louay.bassbouss@fokus.fraunhofer.de>
CC: "public-webscreens@w3.org" <public-webscreens@w3.org>, "public-secondscreen@w3.org" <public-secondscreen@w3.org>
Message-ID: <E386D49E-E8B9-4530-8968-C38D69A683C2@intel.com>
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)?

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
Received on Tuesday, 18 November 2014 14:48:42 UTC

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