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

> > 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.

In addition this, there is the problem of how to report the existence of custom keys, e.g. the keys on the sides of a blackberry device. 

> 
> >> -       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.

This is the pattern that individual sensor/device info can be reported or aggregated into a summary capability. E.g. power.level summarizes the level of all batteries on the system.

Received on Sunday, 4 October 2009 15:30:05 UTC