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

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

From: Mounir Lamouri via GitHub <sysbot+gh@w3.org>
Date: Wed, 07 Oct 2015 10:42:52 +0000
To: public-secondscreen@w3.org
Message-ID: <issue_comment.created-146151260-1444214571-sysbot+gh@w3.org>
The reason why I started to think about another proposal than the 
initial one I made is because there are a few issues with it. We could
 solve these issues by specifying behaviour in the specification but I
 think it will still allow developers to shot themselves in the foot.

- What should be the behaviour of ```waitForConnection()``` if there 
is already one connection? Two? If the first connection has been 
- Given that ```connections``` is asynchronous and I expect that we 
will pass a ```PresentationConnection``` in the 
```connectionavailable``` event, there might be some race conditions 
here. For example: a call to ```connections``` is made, 
```connectionavailable``` fires, ```connections``` promise is 
resolved. What does the ```sequence<PresentationConnection>``` 
contain? All the connections including the new one or not including 
the new one? I think it will be easy for implementers and authors to 
overlook that.

Also, I'm not really convinced that having an asynchronous 
```connections``` property solve all the misusage of the API. For 
example, one could write this:
navigator.presentation.receiver.connections.then(c => c[0].send("I'm 
ready to rock"););
Which would be as wrong as the previous code from Jonas above.

GitHub Notif of comment by mounirlamouri
Received on Wednesday, 7 October 2015 10:42:54 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 October 2015 10:42:54 UTC