Re: Session cancellation and reconnection

Hi Jonas, let me try to clarify -

On Tue, Sep 16, 2014 at 3:29 PM, Jonas Sicking <jonas@sicking.cc> wrote:

> On Mon, Sep 15, 2014 at 2:22 PM, mark a. foltz <mfoltz@google.com> wrote:
> > 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.
>
> Seems fine to me.
>
> >> > * 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).
>
> I still don't think I understand.
>
> Why would the page attempt to call joinSesssion in a loop?
>

So, I think there are at least two use cases for polling to rejoin an
existing presentation.

The first is the case you describe below, where a single opening page is
connected to the presentation, but was interrupted, and it wants to resume
presentation transparently to the user.   If the disconnection happened
because the page was torn down, then checking joinSession() once on page
reload should be fine.  If the disconnection happened because of a network
hiccup (switching WiFi, etc.), then maybe the page wants to periodically
check if connectivity to the presentation becomes available again, and use
a loop like the one above.

The other use case is where the presentation expects multiple controlling
pages, and e.g. able to advertise its URL and presentation id to
other browsers using through some means (a server, etc.)   In this
scenario, a page may want to periodically check if the presentation is
available as the user roams on different networks without requiring a page
reload.

Both of these would be enhancements to the user experience, but I don't
think they are absolute necessities.  Users should be able to
connect/reconnect in either scenario using the manual connection (i.e.
startSession()).


>
> Are you worried that authors will do something like the above and that
> we need to define what happens if they do? If so, why do you think
> that a webpage the webpage would try to accomplish by doing the above?
>
> Or are you trying to solve some use case? If so, what use case?
>

I am not worried about Web authors doing the above, I was trying to project
what they would do if they wanted to check |joinSession()| more than once
and if so, do we need to extend the API for this use case.  In my opinion,
not at this time.

There is still some debate about what to do with the Promise returned by
joinSession() when there is no session to join - do we reject it (giving
the page free range to query available presentations), or do we leave it
unresolved.


> My intent with joinSession was that the page would call joinSession
> from the 'onavailable' handler (be that an event or a resolved
> promise) to see if there's any existing sessions running, from a
> previous crash or similar, that should be resumed. If joinSession
> fails, that means that there's no such session and the page should
> display the normal UI for using a remote screen.
>
> There's no reason to call joinSession after that as far as I could see.
>

Okay, see my potential scenarios above, and feel free to provide an opinion
on how feasible they seem.


>
> > 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?
>
> I guess I don't understand the use case you're trying to solve. I.e.
> what it is that you want pages to be able to do.
>
> >> > * 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).
>
> I have a nagging feeling that we have different mental models for how
> joinSession works, or what it's supposed to be used for. So might make
> sense to clear up that up above first.
>
> / Jonas
>