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

On 6.10.2009 18.36, "ext David Rogers" <> 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". :-)


Received on Wednesday, 7 October 2009 09:37:41 UTC