Re: Quick review of System Info

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?

>> • Is it really necessary to have "optional Foo? foo"? I would assume that if something is optional and you pass null, it means you're not passing it; but if it's marked as nullable that means that you've passed it and it's null. I'm not sure it makes a difference to implementations, but we should agree about the right way across specs here.
> 
> Indeed, I was wondering about it. Since I would like to allow:
> get(property, success, null, options)
> get(property, success)
> get(property, success, error)
> but not
> get(property, success, null, null)
> 
> I suppose the right answer is
> get(DOMString property, SuccessCB success, optional ErrorCB? error,
>    optional options)

I find it hard to tell if that's the best approach, it seems wrong that a type should be nullable just because it's not the last optional parameter. I've posted to public-script-coord to ask for clarification, and will report back with anything useful that's said there.

http://www.w3.org/mid/2667AA0D-D664-4735-A070-35F6A503D365@berjon.com

>> • There is a number of other cases where it says "this method MUST invoke" or similar things. In general if you have a TA and the sentence doesn't mention a product class (probably the "user agent") then something is fishy. Dom has been drafting text about this which we should all read once it's found a home.
> 
> ...until Dom's text is out.

We'll probably need some MUSTs in there :)

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

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

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

>> • Thermometer: "A value of 0.0 means that the system is running at the lowest safe temperature, and a value of 1.0 means that the system is running at the highest safe temparature." Is this typical of thermometer APIs? I was more expecting something in C° (or K°), possibly alongside an indication of whether the system thinks it's unsafe. Should this just use Thermal? It seems that that's what INTERNAL_COMPONENT is for.
> 
>> • Also: "On devices that have multiple thermometers, this value should reflect the average temperature of all the thermometers." That's really not very useful :) My battery's thermometer might be indicating that it's close to exploding, but the DVD's might be just getting some residual heat. Again, this seems like an array would be more useful, especially if it's to warn me that something's going to go toast.
> 
> The reason why I just had a 0-1 value is that indeed you have devices with many temperature sensors, so indeed an average temperature doesn't make sense. (So I should have removed "average" and phrased my statement as "the value should reflect the general temperature state of the system".) And for the same reason as above, I think an array is not what most webapp/widget developers are going to want to bother going through.

In this case though I don't really understand the use case of having a value that isn't a temperature, and I'm not clear as to what the "general temperature state of the system" is. Are you saying that if all is cool except one sensor, it would go close to 1.0 to indicate that explosion is imminent? It doesn't strike me as overly complex to expose an array of thermometers, and if we don't I'd like to know what usage we're addressing :)

>> • General point: I'm wondering if this specification shouldn't be split into a bunch of smaller specifications (which we can do) so that parts could be shipped independently from one another? This would prevent it from blocking if people don't want to implement some part even when there's strong interest in another.
> 
> From an editorial or W3C process point of view it wouldn't be so great.
> I might be wrong, but I really prefer to see a simple specification (at least for the first version) and I'm please that sections like battery are currently no longer than the height of my screen. Perhaps we just want to add some feature string. I know that they are controversial, but they're not any different from separate specifications.

My concern depends on the overall complexity of the specification. If you trim v1 down to something really simple, then I certainly don't mind. I was mostly worried about one aspect slowing the rest down.

--
Robin Berjon
  robineko — hired gun, higher standards
  http://robineko.com/

Received on Tuesday, 8 December 2009 16:00:06 UTC