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

[presentation-api] Behavior of a receiving user agent in reconnecting

From: Tomoyuki Shimizu via GitHub <sysbot+gh@w3.org>
Date: Wed, 05 Apr 2017 07:19:49 +0000
To: public-secondscreen@w3.org
Message-ID: <issues.opened-219490509-1491376788-sysbot+gh@w3.org>
tomoyukilabs has just created a new issue for https://github.com/w3c/presentation-api:

== Behavior of a receiving user agent in reconnecting ==
According to [6.3.5 Reconnecting to a presentation](https://w3c.github.io/presentation-api/#reconnecting-to-a-presentation) in the current spec, when a controlling user agent reconnects to a presentation,

- the user agent searches an existing (closed) presentation connection, otherwise it creates a new presentation connection,
- and the user agent [requests a connection](https://w3c.github.io/presentation-api/#dfn-establish-a-presentation-connection) to a receiving user agent

On the other hand, [6.7.1 Monitoring incoming presentation connections](https://w3c.github.io/presentation-api/#monitoring-incoming-presentation-connections) would imply that the receiving side would always create a new presentation connection (step 2.), regardless of whether the controlling side would use an existing presentation connection or create a new one. I'm afraid that it might cause duplication of presentation connections at the receiving side, since the current spec does not seem to clearly mention behavior of the receiving side in reconnecting, IIRC.

There may be a couple of options like the following:
- remove the presentation connection from the set of presentation controllers when it is closed
- search the corresponding presentation connection instead of creating a new one when a new connection request is received

I believe that the latter one looks better in terms of consistency between controlling and receiving sides. WDYT?

Please view or discuss this issue at https://github.com/w3c/presentation-api/issues/419 using your GitHub account
Received on Wednesday, 5 April 2017 07:19:56 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 5 April 2017 07:19:56 UTC