- From: Jonas Sicking <jonas@sicking.cc>
- Date: Mon, 25 Aug 2014 18:19:44 -0700
- To: "mark a. foltz" <mfoltz@google.com>
- Cc: Marco Chen <mchen@mozilla.com>, Mark Watson <watsonm@netflix.com>, Anton Vayvod <avayvod@google.com>, Anssi Kostiainen <anssi.kostiainen@intel.com>, Wesley Johnston <wjohnston@mozilla.com>, "public-webscreens@w3.org" <public-webscreens@w3.org>, Evelyn Hung <ehung@mozilla.com>
On Mon, Aug 25, 2014 at 5:57 PM, mark a. foltz <mfoltz@google.com> wrote: > On Mon, Aug 25, 2014 at 4:30 AM, Marco Chen <mchen@mozilla.com> wrote: >> >> Hi, >> >> I think the support of multiple controllers is important to benefit some >> use cases. >> The web game can allow multiple players for one. >> >> Maybe we can refer to NSD [1] which provided two EventHandler for >> notifying service found or lost. >> (For Presentation API here, maybe session joined or leaved and under >> NavigatorPresentation) >> Then the session object in presenting page [2] will become multiple ones. >> >> The question is do we allow presenting page to explicitly reject or deny >> second or later sessions? >> (ex: when I choose a game to single player mode then presenting page can >> reject others player.) >> >> [1] http://www.w3.org/TR/discovery-api/#dom-networkservices-onservicefound >> [2] >> http://lists.w3.org/Archives/Public/public-webscreens/2014Aug/0058.html > > > > HTML5 SharedWorkers use an onconnect event handler to let the worker listen > for additional connections [1]. The ConnectEvent names a source > (MessagePort). Perhaps a similar API would work here, e.g. retaining the > onpresent event for new connections. > > [1] > http://www.whatwg.org/specs/web-apps/current-work/multipage/workers.html#shared-workers > > We would still want to address the race condition, either by setting a > property at page load time with existing connections, or requiring the user > agent to queue up connect events and fire them when the first handler is > added. Yeah. Having looked at similar issues in the past, it's hard to get a plain event to work well for situations like this in webpages. It's easier in a Worker because they run in a much simpler environment. With workers once you've done the "top level" execution of the script, you can be fairly sure that all required scripts have been run. So it's pretty safe to fire the "onconnect" right after the top level eval has finished. Exposing an array of connections, as well as firing events whenever connections are added or removed, sounds like it would work well. / Jonas
Received on Tuesday, 26 August 2014 01:20:42 UTC