define the behavior while receiver calls connection.terminate()

[schien]

In section 6.2.4, we only define the behavior that receiver app must be terminate while controlling side invokes connection.terminate(). But what should happen if receiver side invokes connection.terminate()?

Two approaches I have in mind:

1. throw NotSupportedError exception because we don't allow receiver app to close controller app.
2. terminate receiver app itself and notify all connected controlling side to change state to terminated just like the behavior that connection.terminate() is invoked in controlling side.

[anssiko]

Option 2 sounds better from the developer ergonomics point of view i.e. regardless of which side is invoking connection.terminate() the behaviour is the same.

Also, the web developers might expect this work similarly to window.close().

[markafoltz]

The current algorithm for terminating a presentation connection currently implements proposal #2 by @schien; see the text starting "When a receiving user agent is to terminate a presentation using connection..."

http://w3c.github.io/presentation-api/#terminating-a-presentationconnection

However the description could be improved. I think we should split it into two algorithms, one for terminating in the controlling context and one for terminating the receiving context.

I'll leave this issue open until the editorial improvements are made. Pull requests are welcome :)

[markafoltz]

Per @anssiko the implementation is to behave identically to window.close() with the additional step of notifying all connected controllers that the presentation was terminated.

[anssiko]

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() method based on the value of the receiver 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.

[markafoltz]

This should be addressed with the merged PR.