Re: Quick review of System Info

On 08/12/2009 16:59, Robin Berjon wrote:
> On Dec 8, 2009, at 11:07 , Max Froumentin wrote:
>>> • When discussing an interface in prose, it is better not to use<code>Dahut</code>   but rather<a>Dahut</a>   if it's defined in the same document — that way it'll get linked automatically.
>>
>> But if they aren't they remain simple<a>'s that are links that don't point to anything and aren't visible as links. At least it would be nice if they looked like<code>
>
> We could add a class for that, but there's no way I can guess that something in<a>  is an interface defined in a separate specification! For those, you can use<code>, or<a class='externalDFN'>  but that won't give you the style you expect.
>
> That being said, most of the time you know which interfaces you're defining inside your specification, and which are external, no?

Fair enough. Let's just leave it as is.

>>> • Using CURIEs is interesting, but it warrants some introductory discussion. Do we really need to reference CURIEs? In the absence of a mechanism to declare one's prefixes, it doesn't seem to help much. We might just as well define our own short names and tell others that if they want to extend the API they have to use URIs (or vendor-prefixed names).
>>
>> Something I borrowed from Bondi. I think it is indeed interesting, but I must admit I haven't looked into it yet. But I will in an upcoming pass through the text.
>
> Referencing an XHTML 2.0 specification worries me somewhat. And as I said, I'm not convinced that it makes sense to use a CURIE if you have no mechanism to define a prefix. I'd suggest going with just strings, and having the extensibility be done through URIs or vendor prefixes (with a slight preference for the former in this case).

I'll revisit the issue completely anyway. Just the fact that you remind 
me that it's based XHTML2.0 is enough to change my mind.

>
>>> • The order of parameters that is used is successCB, errorCB, options. Is it likely that options will be used more often than errorCB? If so they should be before it.
>>
>> I'm not sure about that, but I'll be happy to follow what others do.
>
> There seemed to be some consensus around it in this thread (though no formal resolution):
>
>    http://www.w3.org/mid/BA309B13-1F2A-450C-B331-1ED65C19DA34@berjon.com
>
> I think Ilkka makes a good point that those will be common enough in our APIs that folks ought to be able to figure them out quickly even if they don't seem 100% obvious the very first time.

I'm certainly not rejecting the requirement that all APIs use the same 
conventions, and I'll abide to what the WG decides, of course. But it's 
not obvious that any consensus around the order of parameters exists.

>
>>> • CPU: is it much of a hassle to expose multiple CPUs right now? If I have an app that can only use a single CPU, it might be maxing out but the system might still report "using 52%" because the other one's idle. It seems like an array of values wouldn't hurt here (and a requirement that they are always in the same order).
>>
>> Following the 80/20 principle, I've not put multiple CPUs in because I doubt that more than 20% of users will care about multiple CPUs, GPUs and whatnot. However, I've left the door open by having the callback return a CpuState object rather than a single value. So you could expand the current type as:
>>
>> interface CpuState {
>>   attribute float load; // global system load
>>   attribute SingleCpu cpus[];
>> }
>>
>> interface SingleCpu {
>>   attribute float frequency;
>>   attribute DOMString info;
>>   attribute float maxFrequency;
>> }
>>
>> I might be wrong, but I wouldn't put it in this version of the specification.
>
> Well on my Mac I need to look at the multiple CPUs because it's often a good clue as to what's going on, but I don't have a strong opinion and am happy to leave it up to you.

I think the question is what use is the "internal sensors" (for lack of 
a better term) API. Either:

1. The API exposes a global system load (CPU-, Thermal- or storage-wise) 
in order for the webapp developer to warn the user, change the webapp's 
behaviour, or activate sensors -- CPU throttle or cooling system. Or,

2. The API exposes the raw data for all the CPU/Thermometers/Fans, in 
order for the webapp developer to decide themselves when to change the 
webapp's behaviour. Or you want the app to expose the raw data to the 
user, like a system monitor

My claim is that use case 2 is very rare. But just having 1 (as in my 
current draft) feels odd, perhaps because the values returned don't have 
units.

In any case, I don't think it'll make a big difference to the API 
implementer to provide both. And as I showed above it doesn't make the 
API much different. Except perhaps for one thing: identifying CPUs or 
thermometers. On this Mac, there are 7 thermometers: HD, CPU, Enclosure 
Base, GPU Diode, GPU heatsink, 2 CPU Heatsinks and Wifi card. How do I 
identify them? const values? There probably won't be enough defined. 
Freeform strings? Then developers can't expect what temperature they're 
getting.

Perhaps we can discuss in an upcoming call to gather more feedback

Max.

Received on Wednesday, 9 December 2009 11:23:21 UTC