- From: Jonas Sicking via GitHub <sysbot+gh@w3.org>
- Date: Thu, 08 Oct 2015 22:40:27 +0000
- To: public-secondscreen@w3.org
> > What happens if you have two parts of the page which both needs access to the connection. > > Does that mean that the second caller of waitForNextConnection will wait for a second connection which is never coming? > Yes. Do you think that could be a common problem? Why wouldn't the page just pass the first connection it receives to its other parts? I don't know how common it will be to have multiple parts of a page which all need access to the list of connections. What I do know is that pages are often vastly more complex than we give them credit for. So I would not be surprised if it will happen more often than we think. For example I would expect people to write frameworks or libraries that take care of a bunch of the connection management. But that those frameworks/libraries won't cover all the cases that a page cares about, and so the page will also use the "raw" API we're defining here. I also know that keeping state known to the browser hidden from pages almost always ends up with developers eventually wanting access to that state. Similarly, defining "smart" APIs which try to hide details from developers more often than not just makes things harder for developers. So having an API which, after you've called `waitForConnection()` once, makes it impossible to get at that connection object again, sounds like something that will be a pain for developers. It creates hidden state which the page author can't get to. > I believe that losing the single connection would be a problem and most of the presentation pages would like to allow users to reconnect, so having waitForConnection() return the new connection sounds useful (the page would call it again when the first connection changes to terminated state, for example). I thought reconnecting means that you're still using the same `PresentationConnection` object? So for reconnecting we wouldn't fire onconnectionavailable nor resolve any "queuing" `waitForConnection()`? > > Make it possible to get a list of connections and get notified whenever that list changes. > I think the multiple connections case is far less common so I'm not sure why we should optimize the first iteration of the spec for that. I agree that we should definitely not *optimize* for multiple connections. But I do think that we should support it. If we should optimize for anything, it should be for supporting a single connection. This is actually why I don't like the current `waitForConnection()` proposal. It seems decent at handling multiple connections, but it seems far from the API that we'd do if we only cared about supporting a single connection. -- GitHub Notif of comment by sicking See https://github.com/w3c/presentation-api/issues/201#issuecomment-146708135
Received on Thursday, 8 October 2015 22:40:30 UTC