Re: [presentation-api] Have the receiving browsing context generate the presentation identifier?

> One problem with having the receiver generate the identifier: we 
won't be able to resolve a new PresentationConnection on the 
controller in a "connecting" state, since we don't yet have the 
identifier from the receiver.

Yes, or the `id` attribute would need to return `null` as long as the 
identifier is not known, but that looks bad.

Anyway, my initial worry misses one counter-example: if the identifier
 is generated by the receiving user agent, two receiving user agents 
could also still create the same identifier for a given presentation 
connected to two different tabs of a controlling user agent. In such a
 case, a page running on the controlling user agent would not be able 
to select the right presentation connection when calling `reconnect`.

I suggest to close this issue: no matter where the identifier gets 
generated, the main issue is indeed that we probably want to reduce 
the likelihood that the identifier may clash with another one created 
in its vicinity. And it does make things more complicated from a spec 
perspective since the spec expects the identifier to be available 
right away on the controlling side.

I created issue #279 (Specify the algorithm for generating a 
presentation identifier) to discuss the generation of the presentation
 identifier.

-- 
GitHub Notification of comment by tidoust
Please view or discuss this issue at 
https://github.com/w3c/presentation-api/issues/253#issuecomment-211945119
 using your GitHub account

Received on Tuesday, 19 April 2016 14:28:16 UTC