Re: [Bug 25707] New: Make getSettings, getNativeSettings, getCapabilities asynchronous

On 5/15/14 4:45 AM, Stefan Håkansson LK wrote:
> On 2014-05-15 03:15, Jan-Ivar Bruaroey wrote:
>> On 5/14/14 8:12 AM, bugzilla@jessica.w3.org wrote:
>>> There may be situations when getting the data may take some time (e.g. reaching
>>> out to devices), so we should not stop the main script. (getConstraints should
>>> be fast)
>> Can't all this information effectively be gathered during and cached
>> beyond the originating gUM or applyConstraint call?
> If that is possible, that would be a really good.
>
> But can't the settings vary over time (even with no changes to the
> constraints)?

Sure, but can they vary over time without involving the UA? if they can, 
then yes, UAs might have to reach out to their device to see how it is 
doing and pull back the latest settings on-demand, which may take time. 
But it seems to me (though I am often wrong) that devices mostly do what 
they're told, so it doesn't seem unreasonable to me to require the UA to 
be able to respond immediately with whatever its current settings are 
without waiting for it to search its pockets.

I'm trying to think of a case where an app needs to know the current 
setting of a camera but the UA doesn't. Worst case, if some camera has 
built-in fallbacks and a UA has no way to detect this except through 
polling (which seems odd, if the UA can't tell then where are the bits 
going?), then it seems prudent to me for the UA to poll this device on 
some frequency to figure out what it's dealing with. In that case, the 
value you get back may be old (which is always true since there's no 
lock or guarantee of duration for a setting), but it'll change eventually.

I'm curious what others think.

(disclaimer: I haven't written any code yet so I may change my mind, but 
this is my best guess)

.: Jan-Ivar :.

Received on Thursday, 15 May 2014 19:25:18 UTC