- From: Mounir Lamouri via GitHub <sysbot+gh@w3.org>
- Date: Wed, 07 Oct 2015 10:42:52 +0000
- To: public-secondscreen@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
disconnected?
- 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:
```html
<html>
<head>
<script>
navigator.presentation.receiver.connections.then(c => c[0].send("I'm
ready to rock"););
</script>
<body>
...
````
Which would be as wrong as the previous code from Jonas above.
--
GitHub Notif of comment by mounirlamouri
See
https://github.com/w3c/presentation-api/issues/201#issuecomment-146151260
Received on Wednesday, 7 October 2015 10:42:54 UTC