- From: Rottsches, Dominik <dominik.rottsches@intel.com>
- Date: Fri, 5 Sep 2014 14:11:55 +0000
- To: "avayvod@google.com" <avayvod@google.com>
- CC: "Kostiainen, Anssi" <anssi.kostiainen@intel.com>, "public-webscreens@w3.org" <public-webscreens@w3.org>
Hi Anton, On Fri, 2014-09-05 at 12:37 +0100, Anton Vayvod wrote: > We all agreed that the |onavaiablechange| event handler is the only > way to handle the fact that the device availability changes over time > otherwise we'd use a Promise for one time check. So we should assume > the page will add a handler to the |onavailablechange| as soon as it > wants to present something. We want, however, to avoid firing the > event immediately with e.available = true in case the UA already > discovered some devices. AFAIK, just because it's inconsistent with > all other event handlers. > > How would you see an async getter work along with the event handler? > Would the page get both the event from the event handler and an async > callback from the getter if the UA only started the discovery when the > event handler was added? I don't think we want to pass the same result > to the page twice. Agree with the summary - and not an easy question - I don't have an immediate answer, I think I need to research whether we can find a previously used paradigm from other Web APIs for this. Regarding your suggestion to have a cached "available" flag alongside - that would indeed be potentially confusing. If possible, let's try to avoid redundancy. Dominik
Received on Friday, 5 September 2014 14:12:28 UTC