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

On Oct 5, 2009, at 14:59 , <> < 
 > wrote:
> I think the operative word here is definitely "sensors", but  
> thinking about
> it, I would keep APIs related to system information and related events
> separate from sensor input. I know that the lines tend to blur  
> there, and I
> have certainly had many debates as to whether the battery charge  
> indicator
> is a "sensor" just as an accelerometer (to give just a quick  
> example). It
> depends on your view of the world, I guess. :-)

Right, and that sounds like the sort of debate that we could spend 6  
months coming up with an answer to, full with a complete ontology to  
differentiate between all the seventeen ways of detecting how many  
angels can dance on our own heads, only for someone to invent a  
completely new thing that doesn't fit. For reference, also see "What  
is a mobile device?", "How many genders are there?", or "How does one  
build a directory structure shared by several people that won't go  
stale within a week?"

> There's a start of a thread about sensors [1], and I know Robin  
> cautiously
> opined [2] earlier that such would fit under System Information and  
> Events.

I wish to stay cautious in this area, but the charter does say "an API  
to access various system services". Technically, anything can be  
lumped in there.

> This could be the beginning of an interesting (and long, and maybe
> unnecessary) philosophical discussion, but in practical terms I'm  
> simply
> concerned about lumping sensors with system events. From a  
> developer's point
> of view a dedicated API for sensor data would probably be more  
> palatable.

Actually, I'm a web developer and I don't even begin to understand  
where the line could be drawn. I sort of sense (no pun intended) that  
there's some form of ontological difference between the thing that can  
give me the battery level and send me events when the level drops  
below a certain value and the other thing that can tell me how far the  
car behind me is and alert me when it gets too close, but whatever  
that difference is it hurts my head to try and figure out  and I'm  
not convinced that even if we could phrase it correctly I'd want  
developers to have to learn it. If we do make some form of universal  
API to "lowish-level stuff that the system knows about" then we should  
make only one.

> The argument for "universality" in API structure applies here as  
> well as
> with system events, of course.

Jere: could you take an action item to describe a universal system  
that would provide for interoperability nevertheless?

My concern is that you need some form of registry at some level.  
Either the registry is the specification:

   device.system.onBatteryChange(successCB, errorCB);
   device.system.onRearViewRadarDistance Change(successCB, errorCB);

Or it's handled through centralised registration:

   device.system.onChange("", successCB,  
successCB, errorCB)

Or it's open-ended:

   device.system.onChange("", successCB,  
", successCB, errorCB)

There are pros and cons to each approach, and maybe there's a mix and  
match that works, or maybe we need to radically go with one. At this  
point in the discussion though, I'm not getting a sense that we know  

We need to keep eyes on the fact that the only thing that matter is  
interoperability, and that having a "universal" API without values to  
pass to it that have a guaranteed meaning, all that we have is an  
interoperable empty box  which isn't very useful.

A question for all the universal API proposals: considering that in  
all instances Easy Things Should Be Easy, And Hard Things Should Be  
Possible, how does one ensure simultaneously that:

   - users can access very common aspects such as the battery level  
without wanting to kill themselves
   - if I have a non-mainstream sensor (LSD quality checker,  
radiotelescope, cat hair densitometer) how is it exposed in a way that  
is interoperable with other vendors of the same stuff?

Robin Berjon
   robineko  setting new standards

Received on Tuesday, 13 October 2009 14:26:39 UTC