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

> (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.

Good.

> 
> (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').

See #5. I think integrating the onTimeout callback into the onFailure callback would simplify things. The Geolocation API has taken this path: when onFailure is invoked, the developer can check the error code and determine if the cause for failure is timeout or permission denied, etc.

> (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.

Agreed.

> (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).

Mandating a polling interval has repercussions on battery life, and unnecessarily restricts implementations that are event driven. A further refinement: All watchable system events MAY specify a polling interval. If a polling interval is specified, a compliant implementation MUST NOT invoke the event more frequently than the specified polling interval. 

> (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).

Agreed.

 
> (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.

Naturally.

> 
> (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.

Agreed. However, there is such a thing as "too granular". For example, if a user grants an application access to data about battery level, I don't see a reason that permission should not automatically extend to information about whether the device is currently using an external power source. Granularity should be limited to functional domains, e.g. power, storage, compass, etc. Google Gears has two functional domains: "Location" and "Local" that latter encompassing Canva, database, workerpool and LocalServer. I think that model is not granular enough.

> 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.

Agreed. Perhaps a standard profile that includes functional domains such as CPU, Display, Power, Connection and Location, and an extended profile that includes other domains such as orientation, movement, ambient light, temperature, etc. The extended profile then would provide a standard means of detecting the validity of data on the host device.

Received on Wednesday, 23 September 2009 15:53:57 UTC