RE: Promise return types

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?

--Richard

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.