RE: Bluetooth / NFC APIs

Hi Max, 

When reading your editor's draft again one question popped up. The high and lowThreshold attributes are included in the general "Options" interface. In the example in the beginning of section 4.8, how do you define which sensor attribute, value or normalizedValue the "maxThreshold: 0.9" attribute refers to? 

Regards
  Claes

> -----Original Message-----
> From: Max Froumentin [mailto:maxfro@opera.com]
> Sent: fredag den 26 februari 2010 11:25
> To: Nikolai Onken
> Cc: Nilsson, Claes1; public-device-apis@w3.org
> Subject: 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 16:09:25 UTC