RE: Requirements: Issue-14 Gathering requirements for System Information and Events API

Fair enough,

Thanks for the comments; I didn't know what the expectation for specifying these requirements is. It is a good discussion to get everyone on the same page.

Regards
Dzung Tran,

-----Original Message-----
From: richard.tibbett@orange-ftgroup.com [mailto:richard.tibbett@orange-ftgroup.com] 
Sent: Wednesday, September 23, 2009 03:40 AM
To: Tran, Dzung D; public-device-apis@w3.org
Subject: RE: Requirements: Issue-14 Gathering requirements for System Information and Events API

 
Hi,

I'm unsure on these requirements, partly because they may be too much to
begin with. I would put the emphasis of requirements on to the
fundamentals of the system events API framework:


(1) All system events MUST be accessible in an asynchronous/non-blocking
way.
<----- I don't need documentation to check whether events are sync or
async. They are all non-blocking and design + development is greatly
simplified.

(2) All system events MUST specify a timeout interval
<----- This requiremenet implicitly suggests that each system event will
require a 'onSuccess' and 'onTimeout' callback (or equivalent methods).
If the timeout interval is reached the onTimeout callback is triggered.
N.B. There could also be a third callback 'onFailure' to handle general
errors from the system event request or underlying platform (e.g.
'Permission Denied').

(3) All system events MUST be watchable (i.e. ongoing async updates can
be received)
<------ i.e. I can watch system events for a specified period of time
and receive async updates  at a specified interval of time with that
specified period of time. See (4) below for parameter requirements of
watchable events.

(4) All watchable system events MUST specify a polling interval (e.g. 60
seconds) and, optionally, a polling timeout interval (10 cycles)
<------ e.g. I will receive a system event update every 60 seconds for a
period of 10 minutes. The polling timeout interval is optional so if not
specified then I will be watching a system event indefinately (or until
clear in (5) below is called).

(5) All watchable system events MUST specify a timeout interval
<------ Same as (2). This implies that watchable events must have two
callback methods (one for success and one for timeout/general errors to
be registered).

(5) All watchable system events MUST be capable of being cleared
<------ I can wait for a watchable to complete or manually tear down the
async process with a clear method.

(6) All system events MUST be independently accessible.
<----- This is a security and policy consideration. I may want to share
my system idle time with a service but not allow that same service to
e.g. see how much storage space I'm still running. This requirement
therefore is that Security and Policy for system events should be
granular.


Then there are the practical considerations:

- An implementation of our requirements MUST be realisable on the
ubiquitous web.
<----- system events explicitly defined MUST apply to ALL devices. I'm
unsure on whether we should then have some kind of different system
event profiles for different devices. A case in point is that a
'vibrate'/'excite' property is not of much use on the desktop, but could
be valuable on a mobile.

- Implementations of our requrements MUST be implementable on different
platforms and devices.
<----- this is subtly different to the previous consideration. We could
specify X number of system events, but these events must be consistently
exposed from ALL underlying platforms/devices. E.g. if we are unable to
'excite' a specific device (because the underlying platform does not
expose APIs to do this), then a 'vibrate' system event is largely
useless in the context of all devices.


Regarding the specific system events in scope, I have no idea...but if a
system event can satisfy both of the practical considerations above then
it's likely to be a good candidate for our API. What is likely is that
the list will be smaller initially based on these practical
considerations. We may lose niche or platform-specific system events but
will gain interoperability on a smaller set of system events. That's a
tradeoff that we have to discuss...


br/ Richard


________________________________

	From: public-device-apis-request@w3.org
[mailto:public-device-apis-request@w3.org] On Behalf Of Tran, Dzung D
	Sent: 22 September 2009 23:00
	To: public-device-apis@w3.org
	Subject: Requirements: Issue-14 Gathering requirements for
System Information and Events API
	
	
		Requirements for System Information and Events API

	*	Any action that might take more than 10 milliseconds
must be available through an asynchronous interface. 
	*	Any action that is expected to take less than 100
milliseconds should be available with a synchronous interface. 
	*	Any synchronous operation that might take more than a
millisecond must provide the option to specify a timeout interval. 
	*	Actions that vary in how long they take and meet both
categories should be available in both synchronous and asynchronous
variants. 
	*	Any continuously varying sensor must allow one to ask to
be told when it changes and must allow one to specify the maximum
frequency with which such change events should be delivered. 
	*	Any change event must include a field saying how long it
was since the last time the sensor was checked (not the last time the
event was fired). 
	*	A conforming implementation must implement the
NavigatorPlatform interface. 
	*	A conforming implementation must implement the
NavigatorPlatform Power interface. 
	*	A conforming implementation must implement the
NavigatorPlatform Connection interface. 
	*	A conforming implementation should implement the
NavigatorPlatform Cpu interface. 
	*	A conforming implementation must implement the
NavigatorPlatform Storage interface. 
	*	A conforming implementation must implement the
NavigatorPlatform Display interface. 
	*	A conforming implementation must implement the
NavigatorPlatform Input interface. 
	*	A conforming implementation should implement the
NavigatorPlatform Geolocation interface. 
	*	A conforming implementation must implement the
NavigatorPlatform Audio interface. 
	*	A conforming implementation must implement the
NavigatorPlatform Video interface. 
	*	A conforming implementation must implement the
NavigatorPlatform Thermal interface. 
	*	A conforming implementation must implement the
NavigatorPlatform AmbientLight interface. 
	*	A conforming implementation should implement the
NavigatorPlatform AmbientSound interface. 
	*	A conforming implementation must implement the
NavigatorPlatform AmbientPressure interface. 
	*	A conforming implementation must implement the
NavigatorPlatform Proximity interface. 
	*	A conforming implementation must implement the
NavigatorPlatform Movement interface.

	Regards
	Dzung Tran, Intel Corporation

Received on Wednesday, 23 September 2009 13:56:25 UTC