Re: joinSession and resumeSession

Hi Oleg!

Thanks for bringing this issue to the attention of the group. Comments
inline:

On Thu, Mar 5, 2015 at 11: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.
>

On one hand, we are trying to keep the API as simple as possible by keeping
the API surface (e.g. number of new methods) minimal. I agree that having
distinctive methods for distinctive functionality is usually a good design
though.


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

I think the cases we wanted to cover with start/joinSession(U, I) are the
following:

1. There's no existing session with the presentation URL *U* and id *I* started
from the current UA.
1a) There's no remote presentations with the matching URL and id known to
the current UA.

In this case joinSession(U, I) will fail with NoPresentationsFound error.
startSession(U, I) will ask the user to select a device if available and
try to start a new session on the device.

1b) There's at least one remote presentation with the matching URL and id
known to the current UA (e.g. available devices advertise running
presentations somehow)

In this case I think joinSession(U, I) should still fail with
NoPresentationsFound.

startSession(U, I) will ask the user to select a device and if the device
with a matching presentation is selected, the returned session may
correspond to the existing presentation on the device (of course, if the
presentation doesn't support multiple clients, a new presentation will
start and connection with the previous client will be dropped).

2. There's at least one existing session with the URL U and id I started
from the current UA.

startSession(U, I) will work the same way as in 1b)
joinSession(U, I) will return the most recent of these matching 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.
>

The session id by the current algorithms is the same as the presentation id
and passing the presentation URL along with it allows the presentation id
to be unique for each presentation URL, but not globally.


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

By the currently specified algorithms in the spec, the session id
<http://session.id> is the presentation id passed to
startSession/joinSession calls or a random string generated by the UA if
startSession was called with an undefined id.


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

Returning a UA generated unique session id in response to start/joinSession
sounds like a good way to allow the page to choose which exactly session to
join but makes it a little harder to share the session ids.


>
> Best regards,
> --
> Oleg Beletski
> Principal Engineer
> Samsung Electronics R&D, Finland, Espoo
> o.beletski@samsung.com
>
>
>
>
>