Session cancellation and reconnection

On Fri, Aug 22, 2014 at 4:55 PM, Jonas Sicking <jonas@sicking.cc> wrote:

> On Thu, Aug 21, 2014 at 8:57 AM, Anton Vayvod <avayvod@google.com> wrote:
> > Each time I see a boolean flag in the parameters list I feel like having
> two
> > functions instead with distinctive clear names instead. Maybe have two
> > functions like this:
> >
> > partial interface NavigatorPresentation {
> >   PresentationSession startSession(DOMString url, DOMString sessionId);
> >   PresentationSession joinSession(DOMString url, DOMString sessionId);
> > }
>
> Yes! I like this!
>
> > Also, what do the function(s) return if the session is not established
> (e.g.
> > user exits the selection UI by dismissing the popup menu or there's no
> > existing session to join) ? An uninitialized useless session object? Or
> > should we change the return type to a Promise that passes a session to
> the
> > caller if it succeeds?
>
> I think returning a Promise is likely going to make for a easier to
> use API. That makes it very clear when connection has been
> established, and when connection failed.
>

The outcome of this sub-thread was a proposal made by Anton and Jonas that
would make the interface look like the following:

partial interface NavigatorPresentation {
  Promise<PresentationSession> startSession(
      DOMString url, DOMString sessionId);
  Promise<PresentationSession> joinSession(
      DOMString url, DOMString sessionId);
}

This would address the following issues raised in the thread:

"Finalize specification for reconnecting to existing presentations"
https://github.com/webscreens/presentation-api/issues/15

"Define return value for cancelled/missing session for
startSession/joinSession"
https://github.com/webscreens/presentation-api/issues/20

Note, also, that the mozilla-dev@ thread expressing intent to implement
uses the start/join flavor of the API (without Promises);

https://groups.google.com/forum/#!msg/mozilla.dev.webapi/Rjvu-cBJ1TY/r0GeiIbDAIcJ

I will begin a PR to revise this specification with this proposal.  The PR
will include an algorithm description to clarify semantics as well.

m.









/ Jonas
>