Re: ISSUE-14: Gathering requirements [System Info & Events]

On Sep 29, 2009, at 09:44 , Max Froumentin wrote:
> On Mon, 28 Sep 2009 19:17:57 +0200, Tran, Dzung D <dzung.d.tran@intel.com 
> > wrote:
> Requirements for System Info & Events:
>> -       Power: battery, wall
>> -       Connection: WIFI, LAN, 3G, ..etc
>> -       CPU: type, id#, model, freq, number
>> -       Storage: hard disk, Solid state, read & write attributes
>
> Also, available space, but then we're entering File I/O territory

I think this is still in the device information domain.

>> -       Memory: RAM,
>> -       Display: # of display, color depth, resolution
>> -       Input: mouse, keyboard
>
> +keypad, voice, stylus

Specifying this is useful but can get scary. Is touch different from  
stylus? (if you're doing your own hit testing, the difference can  
matter). Does the keyboard have 5-way nav? Does it have a Cmd key? F15?

I think that it would be worth trying to define the level of  
granularity that we'd like to have.

>> -       Audio: stereo, 5.1, 7.1 channels, microphone (recording)
>> o       Is this audio codec capability?
>> -       Video: Is this video codec capability? What about recording?
>> -       Thermal: internal, external (ambient)
>> -       Ambient Sound
>> -       Ambient Light (screen adjust due to brightness)
>
> one or several values? (the iPhone has 2 ambient light detectors)

In general I think we should go for multiple unless we're certain that  
it doesn't make sense to do so. And when a global value is useful  
provide that as well. A typical example is battery. You can have  
several, it can be useful to know that you have several, but it's also  
useful to just know the global charge level without summing up all the  
batteries yourself. So you get something like:

interface DeviceInfo {
     // ...
     readonly attribute sequence<Battery> batteries;
     readonly attribute float batteryLevel;
     // ...
};

interface Battery {
     readonly attribute float batteryLevel;
};

This is an approach that can be replicated easily, though of course we  
should check in each case to see if it makes sense.

>> -       Proximity
>
> to what?

Your face. Seriously, the iPhone for instance will switch the screen  
and touch device off when close to something. I'm sure other touch  
phones do the same. It's extremely annoying if you don't happen to  
hold your phone in strict compliance with the way Apple engineers have  
decided that it must be, but on the other hand it does save one from  
dialling with one's earlobe.

>> -       Movement: gyroscope, accelerometer
>> -       Vibrate device
>> -       Compass
>
> As in the existence or absence of a Compass device, right? But not  
> providing a heading, since that would overlap the geolocation  
> specification.
> If that's right, then add: Geolocation device

Agreed.

--
Robin Berjon
   robineko — setting new standards
   http://robineko.com/

Received on Wednesday, 30 September 2009 10:11:47 UTC