Re: Joining an existing application

On Mon, Aug 10, 2015 at 2:47 PM, mark a. foltz <mfoltz@google.com> wrote:
> (1) Does the presenting browsing context get any say into whether
> connections are allowed are not?  Some presentations do not support multiple
> controllers, or a maximum of N (for example a card game).  The current spec
> allows the presenting context to handle 'sessionconnect' by closing the
> incoming connection immediately.

I was thinking about this too. It's definitely something that we could
do, but I'm not sure that the use cases are really strong.

Basically it would have to be a situation when a number of people have
connected to an application running on the TV, say a game. But then
another user wants to replace this with a new session of the same
game.

I'm not sure that this is common enough that we should worry about it
for now? Worst case, the page on the TV can detect that there's too
many people joining, and call window.close() (or a native-app
equivalent thereof) to shut down the application. Then anyone can
reconnect and start up the application fresh.

Or you can shut down all existing connections, and let only the new
user remain connected.

Let me know what you think.

> (2) Assuming the presentation does support multiple controllers, shouldn't
> the user have a choice into whether to connect or replace?  Is the
> presumption that the site would have two buttons:  "Add Player" vs. "New
> game" which would set the flag accordingly?

That wasn't actually the use-case for the opt-in that we had in mind.
The main reason for the opt-in is that supporting multiple controllers
is fairly complex. So we wanted the default behavior to be simple.

Application authors that *do* want to support multiple controllers can
use either the solution that you describe, or can display some UI
after multiple people connect in order to decide if the new party
should be added, or if a new session should be started, and if so with
who.

> (3) If we are giving the user the choice - can the user agent implement this
> without requiring an API change?  For example in response to a start()
> request, the UA could show a "Join" or "New" buttons for the selected
> screen.

I suspect that this is the type of UI that developers will want to be
in control over.

> (4) If we are presenting in 1-UA mode, then the presentation may not be
> join-able, if the browser hosting the offscreen content is not able to
> handle incoming connections.  This may be an implementation limitation
> though, and not a reason to constrain the API.

Good point!

Possibly we may want to enable the website to detect this situation,
so that they can warn users that are trying to join multiple players
to a game where that is not possible. Or to enable the website to
connect the other players to the first user's device using WebRTC, and
only have a single person directly connected to the TV.

I'm happy to have something like that added now, or we can add it
later if we see the need. Right now I don't think anyone is working on
implementing a 1-UA solution which supports rendering the webpage
on-device and send over a pixel stream?

/ Jonas

Received on Monday, 10 August 2015 22:36:02 UTC