W3C home > Mailing lists > Public > public-device-apis@w3.org > October 2009

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

From: <Jere.Kapyaho@nokia.com>
Date: Mon, 19 Oct 2009 10:10:24 +0200
To: <robin@robineko.com>
CC: <public-device-apis@w3.org>
Message-ID: <C701F9A0.8EEE%jere.kapyaho@nokia.com>
On 13.10.2009 17.26, "ext Robin Berjon" <robin@robineko.com> wrote:
> On Oct 5, 2009, at 14:59 , <Jere.Kapyaho@nokia.com> <Jere.Kapyaho@nokia.com>
wrote:
>> 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.

I think there is a difference, although I don't know if it is ontological
rather than practical. Others may disagree, and I know even I do sometimes.
So let's focus on the practical, for simplicity's sake.

This suggests an API design which is orthogonal and somehow extensible,
which, incidentally, is our next point.

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

Sorry, no, but how about intergalactic travel with zero emissions? :-) Well,
I could suggest some design principles that might be useful to apply, once
we agree what we are applying them to...

[examples elided, please refer to the original message]
 
> 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.

The term "interoperability" freaks me out here -- interoperable with what?
If we're looking for a way to get values from some entity, we need an ID for
that entity, and a specification of the value format. Once you know the name
of the entity, you can register to listen for the values by providing a
callback.

The name of the entity could just as well be a URI. It seems to be the most
common method of naming in this context anyway. If URIs seem like too long,
define convenience constants for them.
 
The value format is a variable-length array of values, which could be
heterogeneous. The actual types of the values (i.e. what the client can
expect) are determined by the entity. (For example: one string, three
floats, 16 integers, and finally a boolean, for a total of 21 array
elements. Then again, it could also be an object literal, for convenience.)

The universality is achieved by the fact that in a given specification there
is a set of preregistered URIs which identify event/data sources. For a
given version of the API, say v1, they are documented with a description, a
URI and the expected data format. If more data sources are needed in v2, new
URIs need to be defined, and the new data formats described. Somehow I don't
think it requires much more than that to achieve this mythical extensibility
that we have circled around.

What separates this from other possible arrangements is that there are not
necessarily dedicated, named APIs for all the different sensors, but a
common API that works the same no matter what the data source is. In
practice, this means the difference between "getMagneticFieldStrength() /
getBatteryLevel() / getNetworkSignalStrength()" and
"registerForData('insert-appropriate-uri-here')".

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

This is where the separation of system events and sensors could be useful.
If we think that system events are by some definition "easy" and sensors are
"hard", it is easier for the developer to say:

var batteryLevel = device.system.getBatteryLevel();

than 

device.system.registerForData('http://gobbledygook/battery-level',
myDataCallback);

since system events are often simple values. But since sensors may provide
much more data which requires elaborate processing, the system of setting up
that processing is allowed to be slightly more involved. I think this meets
the ETSBEAHTSBP criteria.

So, if we shoehorn both system events and sensor data into the same API, we
could be making easy things harder than they should be, but also losing some
flexibility in the process. Of course, it could all still work internally
the same (using the more elaborate way), but define convenience APIs for the
most common cases. (<== actually I think this could be the best idea in this
post)

Recap: I think getBatteryLevel() is fine, but I wouldn't want to have a
getWhateverFancySensorValue() function for all the sensors and events. But I
also wouldn't want to have to access all events and sensors the hard way
with a URI and callback.

You'll still have to explain "interoperable with other vendors of the same
stuff". If there is a common data collection API for JS, there must be some
lower layer which massages the vendor-specific differences into the common
format.

--Jere
Received on Monday, 19 October 2009 08:11:24 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:53:39 UTC