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

Dear all,

+1 for Tran's opinion.
I think usage of sensor will be rapidly growing in the various kind of mobile devices(e.g. iPhone). So sensor API for web application should be provided. 
And I believe DAP WG is appropriate place in W3C.

Best regards,
Wonsuk.

> -----Original Message-----
> From: public-device-apis-request@w3.org [mailto:public-device-apis-
> request@w3.org] On Behalf Of Tran, Dzung D
> Sent: Wednesday, October 07, 2009 11:36 PM
> To: Jere.Kapyaho@nokia.com; david.rogers@omtp.org;
> Claes1.Nilsson@sonyericsson.com; robin@robineko.com; jmcf@tid.es
> Cc: public-device-apis@w3.org
> Subject: RE: ISSUE-14: Gathering requirements [System Info & Events]
> 
> 
> If we don't cover sensors in this WG, which WG would cover this? As the
> name of the WG as "Device APIs", it makes sense that we should cover this
> important feature of the device.
> 
> Dzung Tran
> 
> 
> -----Original Message-----
> From: Jere.Kapyaho@nokia.com [mailto:Jere.Kapyaho@nokia.com]
> Sent: Wednesday, October 07, 2009 02:37 AM
> To: david.rogers@omtp.org; Claes1.Nilsson@sonyericsson.com; Tran, Dzung D;
> robin@robineko.com; jmcf@tid.es
> Cc: public-device-apis@w3.org
> Subject: Re: ISSUE-14: Gathering requirements [System Info & Events]
> 
> On 6.10.2009 18.36, "ext David Rogers" <david.rogers@omtp.org> wrote:
> > The question remains as to whether we should consider the subject of a
> sensors
> > API as in-charter. Having re-read the charter, at the moment, I would
> say no.
> > With the existing API proposals we have on the table I think we have a
> large
> > amount of work and scope creep could be dangerous, taking apart any
> other
> > potential IPR concerns.
> 
> The charter says the WG will deliver at least those API specifications
> that
> are explicitly listed. That does not rule out sensors as such, or indeed
> any
> other APIs that are not listed. It's a different matter whether the sheer
> number of deliverables would already prohibit that.
> 
> Important use cases for accelerometers should at least be considered, but
> it
> wouldn't make sense to define just a dedicated accelerometer API, since we
> already know that there are other such sensors too, probably enough to
> warrant a "universal" or extensible framework for sensor data access.
> 
> > Perhaps there is scope to start a separate discussion about the whole
> subject
> > of transducers, not just sensors, With a view to re-chartering once
> there is
> > something on the table (perhaps within the next year)? I wonder if the
> SCADA /
> > PLC community would be interested in that part too?
> 
> Can you elaborate on the concept of transducers in this context? That
> might
> help us determine the need for such a framework as hinted above. Somehow I
> wouldn't think rechartering is necessary with sensors as we know them on
> phones, but based on the little I know about SCADA it suddenly makes me
> think "version 2, if ever". :-)
> 
> --Jere
>

Received on Wednesday, 7 October 2009 14:44:20 UTC