Re: Bluetooth / NFC APIs

Hi,

The current draft's "sensorReading" API (better name welcome) [1] allows
any type of one-dimensional sensor. The only thing to define, basically,
is names of properties and the corresponding meaning of the "value"
attribute. Right now we have:

* "AmbientLight": value is the illuminance, in lux.
* "AmbientNoise": in decibels
* "AmbientTemperature": in degrees C
* "AmbientAtmosphericPressure" in kiloPascals
* "Proximity" in meters.

Nothing prevents us from adding others, it's as simple as adding:
* "HeartRate" in bps
* "AmbientHumidity" in grams per cubic meter
etc.

It really is up to the WG content to decide where to stop. How about you 
suggest a list and we open an issue for the WG to discuss? And because 
you can use any URL as the property name, other sensors can always be 
added as extensions by third parties.

If one dimensional is deemed not good enough (e.g. geolocation) it would 
be simple to add a new interface with 2 values, of course. Or even an 
array of values, for n dimensions. Again the question is when to stop 
adding to the specification. My opinion is not go multidimensional until 
someone comes up with a really compelling scenario.

[1] http://dev.w3.org/2009/dap/system-info/#sensors

Max.


On 25/02/2010 17:23, Nikolai Onken wrote:
> Hi Claes,
>
> thank you for taking time to reply. I had a quick look at the System
> Info API but will have to take some more time and really look into it
> to understand the current state of things.
>
>> A more general to access external hardware/sensors is a future work
>> item. See http://www.w3.org/2009/dap/wiki/FutureWork.
>
> That looks very interesting - if I can be of any help to slowly morph
> the term future into near-future/today I will do my best :)
>
>> Your prototype of a pure web application for heart rate monitoring
>> is covering a common use case. My personal view is that this WG
>> should add APIs for heart rate and step counter sensors to the set
>> of APIs in section 4.8 of the System Information specification.
>
> I also have created another prototype reading the rooms temperature
> and humidity (say you have a sensor in the living room) and another
> prototype measuring weight. After starting to play around with
> sensors, really a whole new world of use cases came up - HTML/JS/CSS
> is the perfect technology stack to write interfaces interacting with
> such data sources (Especially in the mobile context).
>
>> Others, please comment if you have another view on the WG's
>> resolution on external sensor APIs.
>
> I'd be very interested as well to hear what you think, what the best
> approaches are and how we could push these kinds of APIs forward.
>
> Thanks again for your reply,
>
> Nikolai
>
>
>
>>
>> Regards Claes
>>
>>> -----Original Message----- From:
>>> public-device-apis-request@w3.org [mailto:public-device-apis-
>>> request@w3.org] On Behalf Of Nikolai Onken Sent: måndag den 22
>>> februari 2010 22:48 To: public-device-apis@w3.org Subject:
>>> Bluetooth / NFC APIs
>>>
>>> Hi all,
>>>
>>> this is my first post to this group so let me introduce myself
>>> first.
>>>
>>> I am contributor of the Dojo Toolkit and co-founder of
>>> DojoCampus (together with Peter Higgins, Dojo project lead) and
>>> active in the JavaScript community for several years now. I also
>>> co-founded the european based company uxebu, where we offer
>>> JavaScript and mobile consultancy and development services.
>>>
>>> Last month I started a research project (HumanApi.org) which
>>> looks at APIs in the browser and I have built an application
>>> which accesses the iPhones bluetooth stack through the browser:
>>> http://vimeo.com/8915705 (A heart rate monitor) I am now
>>> wondering if there are any drafts of bluetooth or NFC device APIs
>>> which would allow me to communicate with external hardware.
>>>
>>> If there are, is there help needed to push progress and if not,
>>> what can I do to discuss the subject and push its development? I
>>> personally believe that APIs to access hardware would expand the
>>> fields of usage of the browser by a very large magnitude and
>>> would allow developers to enter whole new application scenarios.
>>>
>>> Regards,
>>>
>>> Nikolai
>>>
>>>
>>>
>>> Kind regards / Mit freundlichen Grüßen
>>>
>>> Nikolai Onken - Co-founder, Lead Frontend Architect
>>> http://uxebu.com AJAX and JavaScript Experts Mobile Cross
>>> Platform Solutions
>>>
>>> uxebu Consulting Ltd.&  Co. KG Richard-Strauss-Str. 21, 81677
>>> München onken@uxebu.com Tel.: +49 (0) 89 122 219 626 - 1
>>>
>>> Amtsgericht München, Handelsregister HRA 93461
>>>
>>> Persönlich haftende Gesellschaft: uxebu Ltd. - Sitz München
>>> Handelsregister HRB 176791 Geschäftsführer: Wolfram Kriesing,
>>> Nikolai Onken, Tobias von Klipstein
>>>
>>>
>>
>
> Kind regards / Mit freundlichen Grüßen
>
> Nikolai Onken - Co-founder, Lead Frontend Architect http://uxebu.com
> AJAX and JavaScript Experts Mobile Cross Platform Solutions
>
> uxebu Consulting Ltd.&  Co. KG Richard-Strauss-Str. 21, 81677
> München onken@uxebu.com Tel.: +49 (0) 89 122 219 626 - 1
>
> Amtsgericht München, Handelsregister HRA 93461
>
> Persönlich haftende Gesellschaft: uxebu Ltd. - Sitz München
> Handelsregister HRB 176791 Geschäftsführer: Wolfram Kriesing, Nikolai
> Onken, Tobias von Klipstein
>
>

Received on Friday, 26 February 2010 10:51:23 UTC