W3C home > Mailing lists > Public > public-secondscreen@w3.org > October 2015

Re: [presentation-api] PresentationReceiver: rename getConnection() and getConnections()

From: Jonas Sicking via GitHub <sysbot+gh@w3.org>
Date: Thu, 08 Oct 2015 22:40:27 +0000
To: public-secondscreen@w3.org
Message-ID: <issue_comment.created-146708135-1444344026-sysbot+gh@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 

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 

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
Received on Thursday, 8 October 2015 22:40:30 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 8 October 2015 22:40:30 UTC