Re: [presentation-api] Rethinking availability monitoring

We could just monitor availability as long as the received
AvailabilityListener instance is alive. The downside is that if the 
page
discards the instance but attached a listener to it beforehand, the
instance will live as long as the page. I'm not sure about the use 
case
though when a presentation capable page would want to stop discovery 
unless
it was navigated from. Are there any existing examples why this is 
needed
on a more granular level than "page is closed/navigated"?

The URL and optional parameters could be used for device filtering in 
the
future.

Rather than add a cancel method we could write the 
AvailabilityListener API
as follows:

partial interface NavigatorPresentation {
  AvailabilityListener listenForAvailability(/*DOMString 
presentationUrl,
      params*/);
}

interface AvailabilityListener : EventTarget {
  Promise<boolean> getAvailability();
  attribute EventHandler onavailablechange;
}

The UA would not run discovery if:

   - there were no handlers on onavailablechange
   - there was no unresolved Promise from getAvailability

Even if there were listeners, the UA could also suspend discovery if 
there
was no opportunity to start presentation (i.e., screen was off, tab 
was in
the background, etc.) as a power optimization.

I would like to understand the role of the presentationUrl and params 
in
the API; @avayvod <https://github.com/avayvod>, they were part of your
original proposal.

—
Reply to this email directly or view it on GitHub
<https://github.com/w3c/presentation-api/issues/81#issuecomment-101039366>.


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

Received on Monday, 11 May 2015 22:20:33 UTC