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

What Jan-Ivar describes is what I've always assumed.  If the device can 
change its settings without notifying the UA, might the UA not have to 
poll periodically just to make sure that the 'require' constraints are 
still being respected?  On the other hand, Cullen has referred to cases 
where a slow query of  the device is necessary at API call time, so I 
guess we'll discuss this at the meeting.
- Jim

On 5/15/2014 3:24 PM, Jan-Ivar Bruaroey wrote:
> 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 :.
>
>

-- 
Jim Barnett
Genesys

Received on Thursday, 15 May 2014 20:34:14 UTC