Re: Session cancellation and reconnection

Hi Jonas,

Thanks for the feedback on these open issues.

On Fri, Sep 12, 2014 at 1:08 PM, Jonas Sicking <jonas@sicking.cc> wrote:

> On Thu, Sep 11, 2014 at 5:16 PM, mark a. foltz <mfoltz@google.com> wrote:
> > I have created a pull request that conveys the suggested specification
> for
> > automatic session reconnection.
> >
> > https://github.com/webscreens/presentation-api/pull/23
> >
> > Please note that there are some open issues that were added as I fleshed
> out
> > the specification:
> >
> > * If more than one presentation session exists with the same url and
> > presentationId (on different screens) then what is the behavior of
> > joinSession(url, presentationId)?
>
> Ugh, tricky one.
>
> Maybe leave undefined which one is reconnected to. But have a SHOULD
> or MAY requirement that implementation should attempt to reconnect to
> the same presentation session that this device previously lost
> connection to. And if that doesn't exist, connect to a session that
> doesn't have any devices connected to it. And otherwise choose one at
> random or let the user choose?
>

Here is a simplified version of what you proposed:

|joinSession(url, presentationId)| SHOULD reconnect to the most recently
connected to session that matches the provided |url| and |presentationId|.
If there are multiple sessions available with a matching |url| and
|presentationId|, and none have been connected to before (or the most
recently connected session cannot be determined), then reject the attempt
to join the session.

In the latter case, the web app can fall back to asking the user to
manually connect to the session via |startSession()|, or begin a new
presentation.


>
> > * If the user agent becomes aware of a presentation session after the
> page
> > has already called joinSession, there is no way to notify the page of its
> > existence. Should we use an event handler instead?
>
> I'm not sure I understand the order of events here. You mean that the
> page calls joinSession before the onavailablechange event fires but
> before we've connected to anything? If so it seems fine to just
> connect to that existing session, no?
>

The order of events is I was thinking:

(1) The page calls joinSession(url) and the Promise is rejected because
there's no screen presenting |url|.
(2) The page, wanting to connect to |url| , calls joinSession() in a
setInterval() loop.
(3) A screen known to the browser begins presenting |url| and the browser
becomes aware of the presentation.
(4) The page is able to connect to |url| via the loop in (2).

However in light of a comment in the other thread about not informing pages
about the lack of available screens via the getAvailable() Promise, we can
do the same thing here.  How I propose we handle this:

When |joinSession(url, presentationId)| is called, if no session with a
matching |url| and |presentationId| is available, then the Promise will not
be resolved or rejected.  If a matching session later becomes available,
the Promise will be resolved with that session.

Make sense?


>
> > * If the page calls startSession(url, presentationId) with the same url
> and
> > presenationId as joinSession(url, presentationId), and the latter call
> has
> > not resolved, behavior is not defined.
>
> Is this different from the more general situation of calling
> startSession when there's already an existing sessions with all TVs?
>
> It seems reasonable for the UA to either simply reject the attempt, or
> to show UI to the user allowing the user to terminate the existing
> session and start a new session.
>

I think it's a matter of which Promise gets resolved with the connected
session.  Since |joinSession| is about automatic connection and
|startSession| is about manual connection, I propose that |startSession()|
gets resolved with the connected session (if the user selects a screen) and
|joinSession| is neither resolved nor rejected (per the comment above).


> > * Since we permit multiple opener pages to connect the same presentation
> > page, we need to define how connection and disconnection of these pages
> is
> > communicated to the presentation page (if at all).
>
> I think this is an interesting use case. It could allow for
> multiplayer gaming on a TV for example. Is this the same as issue 19?
>

Yes, I was including it here for completeness.  I don't have a concrete
proposal on this yet.


>
> / Jonas
>