Re: Draft algorithms specification

On Mon, Jan 12, 2015 at 4:34 AM, Rottsches, Dominik <
dominik.rottsches@intel.com> wrote:

> On Fri, 2015-01-09 at 11:48 -0800, mark a. foltz wrote:
> > Has the semantics of close() been discussed in the CG or WG yet?
>
> Not sufficiently - I do agree we need to fill in the expected behavior
> for tearing down sessions.
>
> >  It could mean one of three things:
> >
> >
> > (1) Disconnect this PresentationSession (and only this
> > PresentationSession) from the presentation.
> > (2) Disconnect all PresentationSessions known by this user agent from
> > the presentation.
> > (3) Request that the second screen cancel the presentation (and, if
> > successful, will result in #2).
> >
> >
> > We can go with (1), which is the most conservative approach, but
> > doesn't give a page any way to actually stop a presentation itself.
> > Either the user agent would  provide a mechanism, or it could message
> > the presentation document to call window.close().  I'm fine with that
> > approach (it's consistent with the UX we have for Cast) but I'm
> > curious to hear other thoughts.
>
> On the Intel side, we might need to gain a bit more experience from the
> implementation before we can have a final answer. However, I tend to
> think (3) would be the more meaningful definition of close().
>
> Isn't close() as defined in (1) more or less a no-op? Can't you just
> discard the PresentationSession object and achieve the same?
>

If we attach some meaning to the number of connected PresentationSessions,
it may be a signal that the page no longer wishes to interact with the
presentation document.  The user agent (or second screen) could close the
presentation document automatically after a time once there are no more
connected sessions.  Or the user agent could drop the physical channel
between itself and the second screen once there are no more connected
sessions.  I have been wondering how we prevent "orphaned" presentations
from living forever :)


> In (2), I see an issue with counterintuitive crosstalk to other tabs. If
> I understood your suggestion correctly, that would mean, that another
> tab (from the same origin probably) can disconnect the
> PresentationSession browser wide - and when switching to another tab
> that held a previously connected PresentationSession, it might now find
> itself disconnected, even though the content is still displayed.
>

That's correct.  It is hard to determine whether the connected status
should remain synchronized across tabs without knowing the scenario.  For
gaming, it might make sense as the tabs belong to the same player and you
probably don't want to have the player connected from one page but
disconnected from another.  For video playback from a given site, it might
be that the user wants to disconnect and play back locally on one tab but
retain control of remote playback from a different tab (in essence the tabs
function as independent controllers).

Sending a "please call window.close()" message on the MessagePort level
> is slightly less reliable, in my opinion, than sending that on the
> native side: The receiving end JS might be stuck or have parsing errors
> etc. and not process the request to close.
>
> This is why I think (3) would be the more useful definition.
>

That's a good point. The user agent certainly should provide a way for the
user to terminate presentation independent of the MessagePort or script
execution on either document.  The question is whether the API should have
that capability as well or should it mean something else.  Both (1) and (3)
have arguments for them.   We could have:

- close() to signal that the page no longer wishes to communicate
- cancel() to tell the user agent to terminate presentation (and in so
doing disconnect all sessions).

m.


>
> Regards,
>
> Dominik
>
> >
>
>
>
>