Re: Define return value for cancelled/missing session for startSession/joinSession (#20)

Hi Anssi,

On Wed, Sep 17, 2014 at 2:23 PM, Kostiainen, Anssi <
anssi.kostiainen@intel.com> wrote:

> Hi Anton,
>
> On 16 Sep 2014, at 16:16, Anton Vayvod <avayvod@google.com> wrote:
>
> > So in all cases the promise would become rejected without specifying the
> reason, right?
>
> Actually, I was thinking the other way around. The promise returned by
> startSession() would never be rejected. It is either resolved with
> PresentationSession if the session is successfully established, otherwise
> it would do nothing.
>

Glad I asked to confirm.


>
> Semantics of the joinSession() would be different though, and the promise
> would be rejected if no session is found, and resolved with
> PresentationSession if an existing session is found.
>
> This would address the privacy concern by adhering to the data
> minimization principle.
>
> For example, when the startSession() is called, the following cases would
> do nothing, i.e. the promise would neither be resolved nor rejected:
>
> - the user does nothing
> - the user clicks cancel in the screen picker UI
> - the user selects no screen in the screen picker UI, clicks OK (a good UI
> would prevent the user from clicking OK)
>
> Only if the user picks a screen in the screen picker UI, click OK and the
> session is successfully established the promise would be resolved with
> PresentationSession.
>

I think not rejecting a promise is inconsistent with the promise design and
purpose. Leaving the promise in a hanging state makes it unpredictable and
leaves the site in the hanging state too. The website will have to be
always ready for it to succeed because there's no way to distinguish
between "it takes some time to connect to the device" and "starting the
session failed".

I think rejecting the promise doesn't give anything out about the user. The
UA could show an additional message if it's actually a connection failure
(i.e. with an advice on how to troubleshoot the problem).


>
> Thanks,
>
> -Anssi
>
>

Received on Wednesday, 17 September 2014 14:07:58 UTC