[webcrypto] Replace KeyAlgorithm interfaces with an Object.

[webcrypto] Replace the *KeyAlgorithm interfaces with an Object.

This corresponds with the spec update:
https://dvcs.w3.org/hg/webcrypto-api/rev/309495c2794e

BUG=386734
Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=177637

[eroman, 2014-06-26 19:31:02]

oops, forgot to hit publish on this one :)

[abarth-chromium, 2014-06-26 19:56:18]

https://codereview.chromium.org/340353006/diff/40001/Source/bindings/v8/custo...
File Source/bindings/v8/custom/V8CryptoKeyCustom.cpp (right):

https://codereview.chromium.org/340353006/diff/40001/Source/bindings/v8/custo...
Source/bindings/v8/custom/V8CryptoKeyCustom.cpp:15: class DictionaryBuilder :
public blink::WebCryptoKeyAlgorithmDictionary {
Can we move this class into the bindings directory?  It seems like there's a
general class intertwined with some webcrypto specific stuff.

[sof, 2014-06-26 19:56:51]

https://codereview.chromium.org/340353006/diff/40001/Source/modules/crypto/Cr...
File Source/modules/crypto/CryptoKey.h (left):

https://codereview.chromium.org/340353006/diff/40001/Source/modules/crypto/Cr...
Source/modules/crypto/CryptoKey.h:36: #include "platform/heap/Handle.h"
It'd be good if you could leave this in.

[abarth-chromium, 2014-06-26 19:57:23]

More specifically, DictionaryBuilder makes sense as a general class in the
bindings.  You'll still need some web crypto specific class that knows about the
names of the particular fields you want to put in the dictionary.

[eroman, 2014-06-27 21:43:48]

PTAL, I have added setters to the Dictionary class.

[eroman, 2014-06-27 21:52:19]

https://codereview.chromium.org/340353006/diff/40001/Source/modules/crypto/Cr...
File Source/modules/crypto/CryptoKey.h (left):

https://codereview.chromium.org/340353006/diff/40001/Source/modules/crypto/Cr...
Source/modules/crypto/CryptoKey.h:36: #include "platform/heap/Handle.h"
On 2014/06/26 19:56:51, sof wrote:
> It'd be good if you could leave this in.

Done. However what is the motivation for doing so, it is unreference after the
removal of Member<>.

[sof, 2014-06-28 06:03:35]

https://codereview.chromium.org/340353006/diff/40001/Source/modules/crypto/Cr...
File Source/modules/crypto/CryptoKey.h (left):

https://codereview.chromium.org/340353006/diff/40001/Source/modules/crypto/Cr...
Source/modules/crypto/CryptoKey.h:36: #include "platform/heap/Handle.h"
On 2014/06/27 21:52:19, eroman wrote:
> On 2014/06/26 19:56:51, sof wrote:
> > It'd be good if you could leave this in.
> 
> Done. However what is the motivation for doing so, it is unreference after the
> removal of Member<>.

The class derives from GarbageCollectedFinalized<>.

[eroman, 2014-06-30 19:57:59]

https://codereview.chromium.org/340353006/diff/40001/Source/modules/crypto/Cr...
File Source/modules/crypto/CryptoKey.h (left):

https://codereview.chromium.org/340353006/diff/40001/Source/modules/crypto/Cr...
Source/modules/crypto/CryptoKey.h:36: #include "platform/heap/Handle.h"
On 2014/06/28 06:03:35, sof wrote:
> On 2014/06/27 21:52:19, eroman wrote:
> > On 2014/06/26 19:56:51, sof wrote:
> > > It'd be good if you could leave this in.
> > 
> > Done. However what is the motivation for doing so, it is unreference after
the
> > removal of Member<>.
> 
> The class derives from GarbageCollectedFinalized<>.

Ah thanks for pointing that out!

[sof, 2014-06-30 21:22:57]

On 2014/06/30 19:57:59, eroman wrote:
>
https://codereview.chromium.org/340353006/diff/40001/Source/modules/crypto/Cr...
> File Source/modules/crypto/CryptoKey.h (left):
> 
>
https://codereview.chromium.org/340353006/diff/40001/Source/modules/crypto/Cr...
> Source/modules/crypto/CryptoKey.h:36: #include "platform/heap/Handle.h"
> On 2014/06/28 06:03:35, sof wrote:
> > On 2014/06/27 21:52:19, eroman wrote:
> > > On 2014/06/26 19:56:51, sof wrote:
> > > > It'd be good if you could leave this in.
> > > 
> > > Done. However what is the motivation for doing so, it is unreference after
> the
> > > removal of Member<>.
> > 
> > The class derives from GarbageCollectedFinalized<>.
> 
> Ah thanks for pointing that out!

Not entirely obvious from the header name :) (splitting up Handle.h some is
worth considering doing later, I think.)

[eroman, 2014-07-08 01:37:59]

@abarth: Ping, could you take another look? Thanks!

[abarth-chromium, 2014-07-08 02:07:05]

LGTM

https://codereview.chromium.org/340353006/diff/120001/Source/bindings/v8/Dict...
File Source/bindings/v8/Dictionary.h (right):

https://codereview.chromium.org/340353006/diff/120001/Source/bindings/v8/Dict...
Source/bindings/v8/Dictionary.h:118: const v8::Handle<v8::Value>& v8Value()
const { return m_options; }
No need to return a v8::Handle by const reference.  Just return
v8::Handle<v8::Value>.  It's the size of a pointer.

[eroman, 2014-07-08 03:15:33]

The CQ bit was checked by eroman@chromium.org

[commit-bot: I haz the power, 2014-07-08 03:15:59]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/eroman@chromium.org/340353006/160001

[commit-bot: I haz the power, 2014-07-08 04:20:29]

Change committed as 177637

[haraken, 2014-07-08 04:28:08]

LGTM

FYI, bashi-san is implementing the IDL dictionary and it will make our life
easier :)

https://codereview.chromium.org/340353006/diff/120001/Source/bindings/v8/Dict...
File Source/bindings/v8/Dictionary.h (right):

https://codereview.chromium.org/340353006/diff/120001/Source/bindings/v8/Dict...
Source/bindings/v8/Dictionary.h:69: explicit Dictionary(v8::Isolate*);

Instead of using a constructor, we might want to implement
Dictionary::createEmpty(). It's a bit confusing that Dictionary() doesn't
allocate m_options but Dictionary(isolate) allocates m_options.

[eroman, 2014-07-08 19:24:21]

https://codereview.chromium.org/340353006/diff/120001/Source/bindings/v8/Dict...
File Source/bindings/v8/Dictionary.h (right):

https://codereview.chromium.org/340353006/diff/120001/Source/bindings/v8/Dict...
Source/bindings/v8/Dictionary.h:69: explicit Dictionary(v8::Isolate*);
On 2014/07/08 04:28:08, haraken wrote:
> 
> Instead of using a constructor, we might want to implement
> Dictionary::createEmpty(). It's a bit confusing that Dictionary() doesn't
> allocate m_options but Dictionary(isolate) allocates m_options.

I will send you this change in a new changelist! (Since this one already
landed).

IDL dictionary support is great, is there a bug I can follow to track its
progress? Then I will be sure to update WebCrypto to use it.

[eroman, 2014-07-08 19:27:37]

(I found the related bug number, so no need to respond to earlier question :)