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

I agree with this approach. For the v1, let just concentrate on a set of sensors that we know today on most devices. So, I will start editing the SIE section by next week conference call.

Dzung Tran,


-----Original Message-----
From: public-device-apis-request@w3.org [mailto:public-device-apis-request@w3.org] On Behalf Of Robin Berjon
Sent: Tuesday, October 13, 2009 07:41 AM
To: David Rogers
Cc: public-device-apis@w3.org
Subject: Re: ISSUE-14: Gathering requirements [System Info & Events]

Hi,

On Oct 6, 2009, at 17:36 , 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.

I will leave IPR concerns in the Team's capable hands. I'm willing to  
make the case that the SIE API includes sensors, but I don't  
personally have a strong opinion on this. My main IPR concern is that  
FPWDs are sufficiently feature complete that the LC exclusionary  
period is as meaningless as possible (so that this isn't so much a  
chartering discussion).

Scope creep is always a concern, which is why I don't think that we  
should take anything that's off charter. But to me, SIE is so vaguely  
defined that it's hard to make the case that a Candy Dispenser API is  
out of scope. What I am however *much* more concerned about is  
*feature* creep. I tend to think that v1 specs should be:

   a) as small as they can be while still being useful; and
   b) somewhat future-proof.

Of course, the hard part consensus-wise is (b) because it's hard to  
make people happy about simple solutions for future-proofing (no  
matter how many times they've been shown to work) and complex  
solutions don't work (for more on this topic, see Versioning).

As a result, I'd like to ask sensor-heads for the following:

  - What is the smallest amount of functionality that you would call  
success for a quick v1 (e.g. battery, accelerometer, ethylometer)?
  - What would you see as the path forward for v2?

Given the above we can come up with a Plan. Without that we'll just be  
chasing circles around what to include and how open-ended to be until  
the home's Cow Sensor starts ringing.

--
Robin Berjon
   robineko - setting new standards
   http://robineko.com/

Received on Wednesday, 14 October 2009 06:27:23 UTC