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

RE: Promise return types

From: Vijay Bharadwaj <Vijay.Bharadwaj@microsoft.com>
Date: Fri, 7 Mar 2014 00:09:00 +0000
To: Richard Barnes <rlb@ipv.sx>
CC: "public-webcrypto@w3.org" <public-webcrypto@w3.org>
Message-ID: <67b5c9e16c24448da5b42de55d735320@DFM-DB3MBX15-07.exchange.corp.microsoft.com>
That is a perfectly valid view, and Ryan gave a scenario on the other branch of this thread where it would be valuable. In that case, it seems like we have a different type of spec bug, where the promise is currently correctly typed but maybe the algorithms are not properly specified :)

From: Richard Barnes [mailto:rlb@ipv.sx]
Sent: Thursday, March 6, 2014 3:12 PM
To: Vijay Bharadwaj
Cc: public-webcrypto@w3.org
Subject: Re: Promise return types

>From the perspective of a consumer of the API:

ArrayBuffer is a pretty inconvenient way to return the result, since in order to do anything with it, you need to make a view on it.  I would prefer to return

Returning a JWK as an string/object instead of an ABV seems like a significant feature, not a bug, since otherwise the developer's just going to have to convert it to a string/object himself.  Could we specify that?


On Thu, Mar 6, 2014 at 7:22 PM, 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 Friday, 7 March 2014 00:09:54 UTC

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