Re: Spec for CryptoKey.algorithm and CryptoKey.usages doesn't really make sense

On Jul 12, 2014 6:25 PM, "Boris Zbarsky" <bzbarsky@mit.edu> wrote:
>
> The IDL is:
>
>   readonly attribute object algorithm;
>   readonly attribute object usages;
>
> and the prose is:
>
>   algorithm
>     Reflects the [[algorithm]] internal slot, converting the interface
>     contained within [[algorithm]] to an ECMAScript object, as defined
>     by [WEBIDL].
>   usages
>     Reflects the [[usages]] internal slot, converting the list of
>     KeyUsages to an ECMAScript Array object, which indicates which
>     cryptographic operations are permissible to be used with this key.
>
> First of all, this doesn't really define the behavior.  For example, if I
do .usages twice on the same CryptoKey, will I get the same object or
different ones?  If I modify the .usages value I get and then structured
clone the CryptoKey, will the clone pick up my modifications or not?
"Reflects" is not defined anywhere, so it's not clear what these getters
are supposed to be doing.
>

That is the definition of reflects - i.e. what immediately follows the
comma.

So:
1 - you can't modify what usages returns (short of overriding the getter)
2 - your changes are not reflected, because you are not mutating the
internal slot, you are mutating the result of converting the internal slots
value to the Web IDL type.

If you still feel it is ambiguous (and this was language that seemed to
satisfy the TAG review), please open a bug and we can find better language.

> Note that section 13.5 seems to assume that the things stored in these
slots are structured clonable, which is not obvious to me.  For example,
[[algorithm]] seems to store a Web IDL dictionary, which is not something
that structured cloning makes sense for.
>

Fair point. It needs to be clearer that the IDL types are copied in some
way.

> I suggest that the following be done:
>
> 1)  Clearly define in section 13.3 what sort of things are being stored
in the internal slots.

Please provide sample language, because its not actually clear what you are
requesting.

>
> 2)  Clearly define in 13.4 how the getters produce the thing they return
from the thing stored in the internal slot.  If, as I expect, you want the
returned values to behave nicely as JS objects but not propagate mutations
to the CryptoKey, then what you actually want is to have extra internal
slots (call them [[exposed_algorithm]] and [[exposed_usages]]), fill them
on first get with a JS object version of whatever is in
[[algorithm]]/[[usages] (the exact mechanism by which that JS object
version is produced would need to be defined) and then just keep returning
what's in the [[exposed_*]] slots.  But maybe the goal is some other sort
of behavior?  It'd be good to understand what that goal is.

Why is that desirable behaviour? As it stands, no, mutations are not
reflected from the CryptoKey, because the getter returns a new object -
sane as various DOMString accessors and friends.

>
> 3)  Structured cloning should ignore the [[exposed_*]] internal slots.
What it should do with the [[algorithm]] and [[usages]] internal slots
depends on exactly what sort of things are stored in those slots; we can
figure that out once we decide that part.
>
> 4)  If the [[algorithm]] and [[usages]] internal slots store JS objects,
the exact way those objects are constructed needs to be defined, either by
referencing Web IDL algorithms explicitly or in terms of ES operations.
 Otherwise you'll likely get observable differences between implementations
in terms of how they construct the objects.

Still not clear here.

As currently written, they store IDL objects that are converted to ES
objects on getting.

Structured Clone doesn't seem incompatible with this, given that structured
clone algorithm itself makes use of such terminology.

(ImageData, File, and Blob are three objects that play particularly fast
and lose with details, and they're the prime role models for this spec)

>
> -Boris
>