"Known connection" in reconnect() may be linked to another browsing context #245
Milestone
Comments
tidoust
added a commit
to tidoust/presentation-api
that referenced
this issue
Feb 1, 2016
I split the "set of presentations" into a "set of controlling presentations" and a "set of incoming presentations". The former set is a singleton shared across the browsing contexts running in the controlling user agent (and possibly published to other user agents). The latter set is per receiving browsing context. I also dropped the description of tuples that defined the set of presentations. Unless I missed something, all the information in these tuples is actually exposed by the presentation connection object. The prose makes it clear that all presentation connections share the same URL and ID in the receiving context. The reconnect() algorithm was also updated to cover the case where a PresentationConnection has already been created in the current context for the same URL and receiving browsing context, and the case where the connection state of the PresentationConnection instance retrieved from the set of controlling presentations is "connecting" or "closed". With these changes, given a controlling browsing context, there should be at most one presentation connection for a given URL and receiving browsing context. As such, I don't see any need to parse the set of controlling connections to fire a "connected" event on those that have the same presentation identifier. So I simplified that part in the "Establish a presentation connection" procedure. This commit intends to fix the following issues: - w3c#165 conflict description for uniquely identifying a presentation session - w3c#193 Define a "set of presentations" for the receiving context? - w3c#229 Need algorithm for establishing a presentation connection when the previous connection(s) were closed - w3c#245 "Known connection" in reconnect() may be linked to another browsing context
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The
reconnect()algorithm assumes that the presentation connection S of the known connection found in the set of presentations is directly associated with the current browsing context, and asks the user agent to resolve thePromisewith S directly.However, S may belong to another requesting browsing context of the same controlling user agent. When that happens, a new
PresentationConnectionobject should be created out of S and added to the set of presentations.The text was updated successfully, but these errors were encountered: