Re: Draft algorithms specification

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.

Regards,

Dominik

> 

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