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

On Jul 14, 2014 7:21 PM, "Boris Zbarsky" <bzbarsky@mit.edu> wrote:
>
> On 7/14/14, 9:40 PM, Ryan Sleevi wrote:
>>
>> I didn't think IDL allowed reference loops to happen.
>
>
> If you have a property of type "object", then it might be any object. And
structured cloning a random Object instance will structure clone its value
properties, which might have value properties pointing back to that object
itself.  The structured clone algorithm therefore has to deal with cycles
in the graph being cloned.
>
> If you happen to know that all your things are not actually random
objects but rather something which will not have outgoing links to random
objects when structured cloned, then you may not have this problem, of
course.
>

KeyAlgorithm never will, because its always constructed 'manually', and
after normalization.

The object members are always AlgorithmIdentifiers, which means the
submembers are always primitive IDL types, or, worse case, an ArrayBuffer.
I don't even recall if we ever reflect an AB back.

In terms of exposed properties (those in internal slots, excluding
[[handle]]), we're good.

>
>>  > If your dictionaries can contain types like that, then you have to
>> deal with that, sadly.  And I guess they do.  :(
>>  >
>>
>> We wouldn't have any following normalization, which is always the first
>> step, so it shouldn't.
>
>
> OK.  What sort of members, _do_ you have?
>
> Writing something here that works for a subset of IDL types is likely a
lot simpler than handling them all.  ;)
>
>
>> Shall we cross-check with TAG/script-coord, or defer that for
upstreaming.
>
>
> Letting people on script-coord know is probably a good idea, but I
suspect that there is little that will be objectionable in clearly defining
how to clone an IDL dictionary.
>
> -Boris
>