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

Re: [presentation-api] Rethinking availability monitoring

From: Anton Vayvod via GitHub <sysbot+gh@w3.org>
Date: Mon, 11 May 2015 22:20:31 +0000
To: public-secondscreen@w3.org
Message-ID: <issue_comment.created-101065154-1431382831-sysbot+gh@w3.org>
We could just monitor availability as long as the received
AvailabilityListener instance is alive. The downside is that if the 
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 
though when a presentation capable page would want to stop discovery 
it was navigated from. Are there any existing examples why this is 
on a more granular level than "page is closed/navigated"?

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

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

partial interface NavigatorPresentation {
  AvailabilityListener listenForAvailability(/*DOMString 

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 
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 
the API; @avayvod <https://github.com/avayvod>, they were part of your
original proposal.

Reply to this email directly or view it on GitHub

GitHub Notif of comment by avayvod
Received on Monday, 11 May 2015 22:20:33 UTC

This archive was generated by hypermail 2.3.1 : Monday, 11 May 2015 22:20:33 UTC