Re: Session cancellation and reconnection

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?

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?

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.

> 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

Received on Tuesday, 16 September 2014 22:30:05 UTC