Re: joinSession and resumeSession

Oleg,

Thank you for your perceptive comment.   There is ambiguity in these two
cases:

1 - There are two accessible presentations with the same URL and ID (i.e.
running on two different screens).  If a page calls joinSession with that
same URL/ID it is not clear which should be joined, if any.  This is
captured in GitHub Issue 39.

2 -  There might be a case where two pages are connected to two distinct
presentations with the same URL and ID.  When the browser closes and
reopens, it would be hard to tell which page should join which presentation
- both URLs/IDs would end up in local storage and we end up with case #1.

I think the default behavior in these cases might be to allow the user to
manually reconnect the page to the appropriate presentation (by choosing
the running presentation in response to startSession()).  But I am not sure
the spec completely defines the "manual reconnection" flow yet.

If you have a concrete idea, it would be helpful to post it on the relevant
GitHub issue (#39).

Thanks,
m.




On Thu, Mar 5, 2015 at 3:09 AM, Oleg Beletski <o.beletski@samsung.com>
wrote:

> Hello,
>
> After reading the Presentation API specification I got a feeling that
> functionality for joining the presentation session and resuming of the
> presentation session are not properly separated from each other in the
> document.
>
> I understood joining of the presentation session practically as the case
> when multiple originating pages are trying to connect to the same
> presentation from the different UA. There could be a problem if we have
> same URL/PresentationID opened on different presentation devices. There is
> no way to tell API which screen we want to connect to and there is a
> possibility that there is no recent connection, so API will fail unless we
> allow screen selection to happen again. Not sure if we can solve that
> problem without trying to pass extra information about destination screen
> to joinSession method. That problem already captured in issue #39,
> Resumption of multiple sessions.
>
> Session resumption would happen in case user closes and then reopens UA.
> Now it would be sufficient to pass only PresentationSession id as a single
> argument to resumeSession method (not part of current Presentation API) to
> reactivate the session for given session id (preserved in localStorage).
> That would restore connection to the same Url-PresentationID-Screen
> combination if it is still active.
>
> One more confusing thing is that in the example provided (chapter 5) there
> is an assumption that startSession creates PresentationSession with id that
> is the same as the presentationID given to it. It is the session.id that
> is restored from localStorage as the presentationID and then passed to
> joinSession call.
>
> Did you have any discussion about possibility of having resumeSession
> method or restoring session via session.id? Please let me know if I
> should create an issue for any of those subjects on github.
>
> Best regards,
> --
> Oleg Beletski
> Principal Engineer
> Samsung Electronics R&D, Finland, Espoo
> o.beletski@samsung.com
>
>
>
>
>