Re: Renaming 'join' to 'reconnect'

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

> Hi All,
>
> For a long time I was confused as to how enable multiple parties to
> connect to, for example, a game running on a TV. I think the source of
> confusion was that the only function which sounded like it enabled
> multiple parties to connect was the 'join' function, which required a
> session identifier.


> Fortunately it was explained to me that the 'start' function also
> enables joining an existing application running on the TV. And that
> the 'join' function was only there to allow a device to reestablish
> connection with an existing PresentationSession object on the TV. This
> is needed if a device experience temporary connectivity loss or if the
> device or connecting application needs to be rebooted.
>

That sounds right.  The use cases for join() I had in mind include:

1. The page that started the presentation navigated within the same origin,
and the new page should reconnect to the presentation.

2. The user opens another page from the same origin in a new tab, and the
developer wants to connect the second tab to the presentation immediately.

3. The user closed the tab (or browser) and reopens it later to the
controlling page/origin, while the presentation is running.  The developer
wants to reconnect the page to the presentation automatically.

In all these cases, we're talking about joining to a presentation that was
started from the same browser (or browser profile).  If you want join() to
work across browsers, you could do the following:

A) When "mysite.com" is presented, push the presentation ID that was given
out initially to a cloud service as well as the TV.

B) Have the second browser pick up the ID advertised by the TV and remember
this as a known presentation.

C) When the second browser navigates to mysite.com, have it check its cloud
service for any known presentation id.  (Presumably some user
authentication is required here.)

D) If one is found, call join(ID) to try to connect mysite.com to the
presentation.

However (at least in our experience with Cast) this auto connect behavior
across browsers might be a bit surprising to users, so we have been more
conservative and required the user to explicitly connect an additional
browser to the presentation via the start() flow.

It might be nice to make this more clear in the naming of the API.
> Maybe by renaming 'join' to 'reconnect' or 'resume' or some such?
>

I agree that join is not the best name.  Perhaps connect() covers use cases
#1-#3: since you can connect an additional controller, or reconnect after
navigation or restart.


> Also, I just noticed that the 'join' function no longer takes an 'id'
> argument in the WebIDL of the PresentationRequest interface. This
> seems like a bug since the description of the 'join' function still
> has the 'id' argument?
>

That's a spec bug, thanks for pointing it out :)

I'll start a PR to address this and your other comments.


>
> / Jonas
>
>