Re: [presentation-api] Rethinking availability monitoring

Hi All,

First of all, I agree with Anssi, that availability monitoring could 
be improved and because of multiple reasons. One of the reasons is 
that current API design makes it very simple for web developers to 
start continuous monitoring and then to forget stopping it. Discovery 
is expensive process that could  prevent device from entering power 
saving/efficient mode. 

I also agree that it is good to optimize the most common one "Find out
 whether there are available display(s), and if yes, show content on 
the display chosen by the user." I would like to make an addition to 
that description -  "if external device is not found then stop 
monitoring and forget that we ever wanted to use the second screen". 

Then there is a less common case that we still need to support - "Find
 out whether there are available display(s), and if yes, show content 
on the display chosen by the user." + keep monitoring for new devices 
because there could be better presentation destination appearing in 
the future. We should keep discovery process running in that case. 
Additionally, we  need to provide for developers an explicit mechanism
 for stopping discovery then.

After listing  those cases side by side I realized that I have already
 seen that approach implemented in Geolocation API [1]. There are 
three methods: to acquire position once, to start continuous watching 
and stopping the watch. We can follow the same pattern here:

```
partial interface NavigatorPresentation {
  Promise checkForAvailability(/*DOMString presentationUrl, params*/);
  Long watchForAvailability(/*DOMString presentationUrl, params*/);
  clearAvailabilityWatch( long watchId);
}
```
Method checkForAvailability runs discovery one time and stops after 
that. Last two methods would provide exactly the same functionality 
that is available in current design with callback attribute 
onavailablechange and corresponding event. New approach makes 
developers aware that browser starts doing extra work when monitoring 
in active. All that clarity comes with the price of adding new methods
 to proposed API. The other thing is that proposal mixes promises and 
callbacks together. I am sure, there might be a better way to design 
it.

[1] http://dev.w3.org/geo/api/spec-source.html#geolocation_interface

-- 
GitHub Notif of comment by obeletski
See 
https://github.com/w3c/presentation-api/issues/81#issuecomment-96709089

Received on Monday, 27 April 2015 15:28:48 UTC