Re: Joining an existing application

On Thu, Aug 6, 2015 at 5:43 PM, Jonas Sicking <jonas@sicking.cc> wrote:

> Hi All,
>
> In a recent call between Google and Mozilla we discussed some details
> of how it would work when multiple parties wanted to join an
> application running on the TV.
>
> In that call consensus was that it would be good if the connecting
> party could opt in to the ability to join an already running
> application. So we would have two modes:
>
> By default, when a session is start()ed, it always replaces any
> running applications on the TV. If the existing origin is already open
> on the TV, it shuts down the current page, disconnects any existing
> session, opens the requested URL and establishes only the new session.
>
> However, when the session is initiated, the initiating page can opt in
> to enabling joining an already running application. If the application
> is not running, then whatever application is running is shut down, its
> connections disconnected, and the new application is started. But if
> the application is running, then we simply fire the "sessionconnect"
> event.
>
> We should probably enable this opt-in through an additional argument
> to the PresentationSession constructor. We could also do it as an
> additional argument to the start() function, but that would mean that
> it can't be used for default sessions.
>

I wasn't able to participate in the call, but this brings a few things to
mind.

(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.

(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?

(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.

(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.

m.