Re: Generalizing the stats hierarchy

On 09/28/2012 07:37 PM, Martin Thomson wrote:
> On 28 September 2012 02:54, Harald Alvestrand<harald@alvestrand.no>  wrote:
>> On 09/27/2012 06:35 PM, Martin Thomson wrote:
>>>     any getValue(DOMString key);
>> Except that Webkit's IDL doesn't support "any" in any meaningful sense...
> That must be hard.
>
>>> I assume that getValue("") would enumerate the top of the tree (""
>>> being the empty JSON pointer that identifies the root, as opposed to
>>> "/" which identifies a node with a key of the empty string)?
>> Are you assuming that getValue("") would function like getNames("")?
>> I'm not sure what you mean here.
> Sorry, I meant getNames("").  getValue("") would have to return a
> composite value unless by chance your entire stats structure was a
> single primitive.
>
>>> Note the added complexity involved in enumerating values in your proposal.
>> Adam Barth told me that having attributes as arrays implies that you can
>> modify those attributes. They're pass-by-reference, not pass-by-value. This
>> isn't what we want; it makes no semantic sense to have stats be modifiable.
> That is true.  But it need not be a deal breaker.  As long as the
> returned values are copies of the information, users can modify the
> entire structure as they like with no consequence to the operation of
> the session.
Yep, and the easy way to specify "returned values are copies of the 
information" is to have it as a function returning sequence<Object> 
instead of an array attribute.
Whatever works.
>
>> A certificate is a primitive object, isn't it? The moment you start taking
>> it apart, it loses its certificate-ness, since you can't verify the
>> signature any more. Can you point to other APIs that handle certificates in
>> a sensible manner? I don't want to reinvent anything I can avoid
>> reinventing.
> There's the certificate as an abstract concept, the concrete
> realization of the certificate in its entirety (the DER encoded
> octets), and all sorts of information *about* a certificate: subject
> DN, issuer DN, fingerprint(s), whether the browser things it is OK
> (and how it reached that conclusion), the public key, the signing
> algorithms, etc...  That information is all potentially useful.
>
> See "openssl x509" for one example.
> And this is probably sufficient:
> http://html5labs.com/cu-rtc-web/cu-rtc-web.htm#idl-def-CertificateInformation
You mean this?

[NoInterfaceObject]
interfaceCertificateInformation  {
     static|CertificateInformation|  <http://html5labs.com/cu-rtc-web/cu-rtc-web.htm#idl-def-CertificateInformation>  getLocalCertificate  <http://html5labs.com/cu-rtc-web/cu-rtc-web.htm#widl-CertificateInformation-getLocalCertificate-CertificateInformation>  ();
     readonly attributeArrayBuffer              certificate  <http://html5labs.com/cu-rtc-web/cu-rtc-web.htm#widl-CertificateInformation-certificate>;
     readonly attributeDOMString                subject  <http://html5labs.com/cu-rtc-web/cu-rtc-web.htm#widl-CertificateInformation-subject>;
     readonly attributeCertificateFingerprints  fingerprint  <http://html5labs.com/cu-rtc-web/cu-rtc-web.htm#widl-CertificateInformation-fingerprint>;
};


Seems simple enough.... I was thinking of whether we have an existing, 
deployed API that people are using to handle cert information. If we can 
avoid new, creative solutions when I can, I'm happier - we have lots of 
them already. If we can't ... we'll just eat that camel too.
>>   The first iteration of stats will be a rough user experience, because
>> we don't know the user yet.  I want to make sure we can get some
>> useful numbers out in the first iteration, and then iterate.
> The discussion over what interface is most suited to conducting
> experiments is different to the one that I imagined we were having.
> If the intent is to conduct this as an experiment, then that is good.
> If you wish to use a well-understood interface in the interests of
> avoiding unforeseen problems, Matthew's suggestion to use SNMP is not
> unreasonable.
As former AD in charge of standardizing SNMPv3 (ca 1998), I can 
certainly sympathize with people who regard any suggestion to use SNMP 
as unreasonable :-)
It's a suggestion that doesn't take many words to state, but it brings a 
ton of baggage with it.