- From: Anssi Kostiainen via GitHub <sysbot+gh@w3.org>
- Date: Tue, 15 Dec 2015 09:39:59 +0000
- To: public-secondscreen@w3.org
It sounds like we're settled on option 2? To provide further data, I'd
like to note the behavior in option 1 could be provided as a polyfill
rather easily:
Given option 2 implemented natively, a web developer could implement
option 1 in JS to alter the behaviour of the [`terminate()`][1] method
based on the value of the [`receiver`][2] attribute:
```
PresentationConnection.prototype.terminate = function (args) {
if (navigator.presentation.receiver instanceof PresentationReceiver)
{
// in a receiving browsing context
throw new Error('NotSupportedError');
} else {
// in a controlling browsing context
terminate.apply(this, args);
}
};
```
The opposite (option 1 implemented natively, option 2 in JS) would be
slightly trickier.
Looking this from the use case perspective: are there good use cases
that would require throwing an exception if the receiving side calls
`terminate()`? Unless the most common code path would require us to
throw I believe we should stick with 2.
[1]:
https://w3c.github.io/presentation-api/#dom-presentationconnection-terminate
[2]: https://w3c.github.io/presentation-api/#dom-presentation-receiver
--
GitHub Notification of comment by anssiko
Please view or discuss this issue at
https://github.com/w3c/presentation-api/issues/222#issuecomment-164702377
using your GitHub account
Received on Tuesday, 15 December 2015 09:40:01 UTC