W3C home > Mailing lists > Public > public-secondscreen@w3.org > April 2017

[presentation-api] Relax `terminate` algorithm to deal with other states?

From: François Daoust via GitHub <sysbot+gh@w3.org>
Date: Wed, 12 Apr 2017 09:50:16 +0000
To: public-secondscreen@w3.org
Message-ID: <issues.opened-221208734-1491990614-sysbot+gh@w3.org>
tidoust has just created a new issue for https://github.com/w3c/presentation-api:

== Relax `terminate` algorithm to deal with other states? ==
The `terminate` method only has an effect on a presentation connection whose state is `connected`.

I think a common scenario for calling `terminate` is when the controlling browsing context is about to disappear or when the user clicks on a button, to clean things up, regardless of the current application state.

This is what we try to do in the test suite for instance, so that subsequent tests start from a clean "no on-going presentation" state. However, since `terminate` only works on `connected` presentations, terminating a presentation no matter what turns out to be more complex that simply calling `terminate`, leading to code such as:

```js
// Try to terminate the presentation
connection.terminate();

// If state was "connecting", previous call did nothing,
// wait for the "connect" event
connection.onconnect = () => { connection.terminate(); };

// If state was "closed", we need to reconnect first. This will return a
// presentation in "connecting" state. Previous event handler will eventually
// take care of it if it's the same "connection", but it may not be.
if (connection.state === 'closed') {
  request.reconnect(connection.id).then(c => {
    c.onconnect = () => { c.terminate(); };
  });
}
```

I'm wondering whether the user agent could take care of some of that complexity, ideally so that developers can end up with a simple `connection.terminate()` call. This would require relaxing the `terminate` algorithm so that:

1. It also applies to connections in the `connecting` state. The user agent would wait for the underlying connection to become `connected`.
2. It also applies to connections in the `closed` state. The user agent would attempt to reconnect the underlying connection before it terminates it.

The latter change may be more problematic, and it seems reasonable to expect applications to deal with connections in the `closed` state themselves. The former change seems easier and useful. If both changes are in place, developers can just issue a call to `connection.terminate()` and be done with it. If only the former change is in place, developers would have to write something like:

```js
if (connection.state === 'closed') {
  request.reconnect(connection.id).then(c => { c.terminate(); });
}
else {
  connection.terminate();
}
```

... which seems acceptable.

Please view or discuss this issue at https://github.com/w3c/presentation-api/issues/421 using your GitHub account
Received on Wednesday, 12 April 2017 09:50:23 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 12 April 2017 09:50:23 UTC