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

RE: Promise return types

From: Vijay Bharadwaj <Vijay.Bharadwaj@microsoft.com>
Date: Thu, 6 Mar 2014 21:00:39 +0000
To: Ryan Sleevi <sleevi@google.com>
CC: "public-webcrypto@w3.org" <public-webcrypto@w3.org>
Message-ID: <83e8363000534adfbb27a41bab52c339@DFM-DB3MBX15-07.exchange.corp.microsoft.com>
I totally understanding wanting to do other things like Stream for say encrypt and decrypt. It’s things like export that I have a harder time with.

From a programmer perspective, it seems to me that exported blobs would generally not be parsed locally, so requiring the JWK to be serialized is fine since it is something the script would have to do in any case. Do you see use cases where someone would get back a JWK object from exportKey and do something other than immediately serialize it?

From: Ryan Sleevi [mailto:sleevi@google.com]
Sent: Thursday, March 6, 2014 12:44 PM
To: Vijay Bharadwaj
Cc: public-webcrypto@w3.org
Subject: Re: Promise return types

The <any> types were actually part of the attempt to allow Microsoft (and others) to explore with other return types - such as Promise<Stream>

I do think it's weird that exportKey returns the serialized JWK - rather than an object that matches a JWK definition. As I understand it, this was largely because methods can only return Interfaces, and so we would have had to define JWK interface?

On Thu, Mar 6, 2014 at 11:22 AM, Vijay Bharadwaj <Vijay.Bharadwaj@microsoft.com<mailto:Vijay.Bharadwaj@microsoft.com>> wrote:
Someone asked me a question recently that made me look more closely at our return types for the subtleCrypto functions. Should we look at tightening these up a bit instead of having them all be Promise<any>?

Specifically, is there any reason to have exportKey and wrapKey return Promise<any> instead of Promise<ArrayBuffer>? The way it’s set up now, it would be very tempting for someone adding a future algorithm to, say, return an object for the JWK export instead of serializing it first as all the existing algorithms do. This may develop into a hassle for programmers as they would have to track what each algorithm does for each format.

Received on Thursday, 6 March 2014 21:01:27 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:02:41 UTC