W3C home > Mailing lists > Public > public-secondscreen@w3.org > January 2015

Re: Draft algorithms specification

From: Rottsches, Dominik <dominik.rottsches@intel.com>
Date: Mon, 12 Jan 2015 12:34:59 +0000
To: "mfoltz@google.com" <mfoltz@google.com>
CC: "Kostiainen, Anssi" <anssi.kostiainen@intel.com>, "fd@w3.org" <fd@w3.org>, "public-secondscreen@w3.org" <public-secondscreen@w3.org>, "public-webscreens@w3.org" <public-webscreens@w3.org>, "avayvod@google.com" <avayvod@google.com>, "markdavidscott@google.com" <markdavidscott@google.com>
Message-ID: <1421066099.7548.13.camel@intel.com>
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?

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.

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.




Received on Monday, 12 January 2015 12:35:33 UTC

This archive was generated by hypermail 2.3.1 : Monday, 12 January 2015 12:35:33 UTC