Re: Session cancellation and reconnection

On Wed, Sep 17, 2014 at 2:58 PM, mark a. foltz <mfoltz@google.com> wrote:
>> > 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.

Ah! If there's a network hiccup a connection is lost, I would expect
that to both result in the session getting disconnected, and that
navigator.presentation.onavailablechange fires, with .available=false.

Once the hiccup is over, I had expected that
navigator.presentation.onavailablechange fires again, with
.available=true. At that point the page could call joinSession again
in order to reconnect.

So no looping would be needed.

However, writing this I wonder if my mental model is correct.

First off, does this match the capabilities of the underlying network
protocols? I.e. can we detect the presentation device quickly enough
again once we have connectivity back?

Second, calling joinSession() again will yield a new
PresenationSession object. Maybe we should instead, or in addition,
have some form of PresentationSession.reconnect() function?

Alternatively, should PresentationSession objects automatically
reconnect if they were disconnected due to network issues rather than
either side explicitly calling .close()?

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

This might be true. I feel like we need to take a larger look at how
the multiple-controlling-pages scenario affects the API.

/ Jonas

Received on Monday, 13 October 2014 05:11:00 UTC