Re: Joining an existing application

On Mon, Aug 10, 2015 at 3:35 PM, Jonas Sicking <jonas@sicking.cc> wrote:

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

I agree for now.  The web developer can handle this case by either
replacing an existing session, queuing the session, closing the session, or
closing the entire presentation.  If there's a specific use case to set the
maximum number of connected sessions, then this can be added to the spec
later.


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

Another way to achieve this on the controlling side is to add a unique or
random token to the presentation URL.  By definition this is a new
presentation and would replace an existing URL.  But it's a non-obvious
mechanism and it might be better to have an explicit API to support this.

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

So the PresentationRequest constructor might look like:

[Constructor(DOMString url, optional boolean allowConnectOnStart)]

|allowConnectOnStart| would default false (resulting in the current
behavior).  If set to true, the browser would try to add the controller as
an additional session if it can verify the display is showing |url|.  Maybe
in this case user agent lets the user choose whether to connect or replace
(as a shortcut to closing the existing presentation and trying again).


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

https://code.google.com/p/chromium/issues/detail?id=490890

:-)


>
> / Jonas
>