Re: Generalizing the stats hierarchy

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.

> So my current implementation has gone from arrays to functions returning
> sequence<object> instead.
> (The fact that array-valued attributes of complex types don't seem to work
> with the current WebKit is a different matter. I won't explore that just
> now.)

That works.  For exactly the same reason as above.

> The other thing I don't like about this is

?

>> A candidate pair can only map to a single candidate on each end, so
>> your mapping is really just 2 lots of a 1:N mapping (one local, one
>> remote).
>>
>> I'm reluctant to suggest it, but this is really a situation where UML
>> really does help.
>
> I'll leave it to you to supply the drawing ....

I might have one lying around that can be tweaked a little...

> Not sure certificate handling is a stats operation. But if it is....

I'm not sure either, but it could just be that stats is a euphemism
for operational interface.  That is, an interface that grants insight
into the operational state of the "system".  In that context, the
scope expands to include these sorts of things.  Given the limits of
the other aspects of API surface, an operational information interface
seems more appropriate.

> 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

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

Received on Friday, 28 September 2012 17:38:21 UTC