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

> 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()?

I meant a case when the user launches a presentation (e.g. a video) on
 the screen and then the controlling device loses Wi-Fi or runs out of
 power - the presentation should continue playing or maybe pause and 
wait for the user to connect from the rebooted or even another device.
 In this case the first PresentationConnection would definitely go to 
the terminated state and the page would have to wait for another one. 
So using only one PresentationConnection at a time doesn't mean using 
the one same connection during the lifetime of the presentation.

> 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 would expect the libraries to give access to the existing connection
 so the page doesn't have to use the API for that esp. if the spec 
will say the same connection can never be obtained again via the API. 
I'd say that compared to the above problem of reconnecting, the 
problem of libraries doing the wrong thing is less important.

> 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.

I don't think it's that far: the only difference is how it would 
behave if called twice - return the same connection or wait for the 
other one. Maybe we should spec that it will return the same 
connection until it's terminated and then it will return the next one 
that's not? Then we might have two methods to also support multiple 
connections:
```
interface PresentationReceiver {
  // Returns he first PresentationConnection in the queue that has 
non-terminated state. Will return the      
  // same connection until it becomes terminated, then will move on to
 the next one.
  Promise<PresentationConnection> getActiveConnection();

  // Returns the next connection in the connections queue; never 
returns the same connection.
  Promise<PresentationConnection> getNextConnection();
```

> 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.

I definitely agree but it depends on the algorithms defined in the 
spec, too, doesn't it? If the behavior of "smart" methods is well 
defined, it's no longer magic, it's just convenient.

-- 
GitHub Notif of comment by avayvod
See 
https://github.com/w3c/presentation-api/issues/201#issuecomment-146729553

Received on Friday, 9 October 2015 01:09:16 UTC