W3C home > Mailing lists > Public > public-webcrypto@w3.org > July 2014

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

From: Ryan Sleevi <sleevi@google.com>
Date: Mon, 14 Jul 2014 18:40:43 -0700
Message-ID: <CACvaWvbhVXGJcjv=wOR9EHmQy8_5qs7FgKh0tv_cJeCmae03ig@mail.gmail.com>
To: Boris Zbarsky <bzbarsky@mit.edu>
Cc: Domenic Denicola <domenic@domenicdenicola.com>, public-webcrypto@w3.org
On Jul 14, 2014 6:30 PM, "Boris Zbarsky" <bzbarsky@mit.edu> wrote:
> On 7/14/14, 7:11 PM, Ryan Sleevi wrote:
>> So we're on the same page, I'm imagining that it would (effectively) be
>> something like http://heycam.github.io/webidl/#es-dictionary 's step for
>> converting an IDL dictionary type to an ECMAScript Object, except that
>> instead of DefineOwnProperty, it's something like "construct an IDL
>> value whose type is the type member is declared to be of and that
>> represents the same value as member on source."
> No, that doesn't quite work.  Defining this generically is a bit of a
PITA.  For example if the dictionary member type is a typed array or
"object" then you actually want to apply the structured cloning algorithm
to it (and keep track of reference loops and the like like the HTML spec

I didn't think IDL allowed reference loops to happen.

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

> If we decide to take this approach, I'm happy to help write this part of
the spec.  Especially since in the long term it should move into Web IDL
anyway, as I said.
> -Boris

I think that'd be great, in as much as it works for me.

Shall we cross-check with TAG/script-coord, or defer that for upstreaming.
Received on Tuesday, 15 July 2014 01:41:10 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:17:23 UTC