W3C home > Mailing lists > Public > public-device-apis@w3.org > December 2009

Re: [sysinfo] draft ready for review

From: Doug Turner <w3c@dougt.org>
Date: Fri, 18 Dec 2009 10:13:17 -0800
Cc: "public-device-apis@w3.org" <public-device-apis@w3.org>
Message-Id: <D17D53AF-60A2-4658-9090-FEB267C9EF79@dougt.org>
To: Max Froumentin <maxfro@opera.com>
nice work Max.  these are my first pass comments:




1) Have you considered just using dom events?  If we do without the Options and ignoring .set(), we could simple do something like:


addEventListener("PowerState", callback);

callback(info) {
  alert("Low battery level: " + info.level);
}


Then any changes in PowerState would call callback.  Also, when addEventListener is called, callback is called schedule to be called as soon as possible to provide the current PowerState (to simulate .get()).


2) Maybe we can roll get and watch together into one api.  I am not sure the value of having two different methods are -- one for one time shot, and one for watching changes.



3) I suggest removing:

Error.message for similar reasons to why it was removed from the geo spec.


4) I suggest removing:

const unsigned short UNKNOWN_ERROR = 0;

I am not convinced that this error code is any better than INFORMATION_UNAVAILABLE


5) I really don't like the Threshold and id values on Options.  For example, given if I want to watch() PowerState, what do these values mean.  Maybe we define a PowerStateOption (and a *StateOption) that we can clearly spec what these threshold values mean.


6) timeRemaining in milliseconds?  i would have thought seconds would be good enough.

7) CpuState - have you considered moving 'load' into cpu?

8) Cpu id - Do we want to spec this string out a bit more so that web developers don't have to struggle parsing it?

9) maxFrequency, minFrequency - optional?


10) nit:  the white space of the ThermalState declaration is off.


11) the attribute 'info' on some of the sensors that describe the sensor -- I am not sure that is really needed; could we make these optional.


12) Connection ipAddress - An implementation must support both IPv4 and IPv6.  What is the format of this string; is it either a IP4 or a ip6?

13) Have you considered moving:

    readonly attribute float?       currentSignalStrength;
    readonly attribute unsigned int currentDownloadBandwidth;
    readonly attribute unsigned int currentUploadBandwidth;
    readonly attribute DOMString    ipAddress;

Into the Connection object?


14) Have you considered adding the MAC address of the router to Connection?  (use case: WiFi positioning).

15) Given that this is a pretty long list of sensors, maybe we should add orientation, acceleration, and compass.  Theses are suppose to be done in the W3C Geolocation WG, but I do not see why they can't be added here... they are pretty small additions and do not have exactly the same privacy concerns.


16) I am sure that the "Privacy considerations for implementors" is going to be discussed a bunch.  One of the ideas that we might want to consider is allowing some property ids not have to prompt. For example, maybe PowerSource is something that we would like to generally expose without having any permission being granted.



I am sure I have more comments, but my quarter ran out.

Thanks Max for putting this together.  Great start.

Doug Turner









On Dec 18, 2009, at 4:27 AM, Max Froumentin wrote:

> Hi WG,
> As promised on Wednesday, I'm submitting a SysInfo draft for review. It is at: http://dev.w3.org/2009/dap/system-info/
> 
> Max.
> 
Received on Friday, 18 December 2009 18:13:53 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:14:03 GMT