- From: Adam Barth <w3c@adambarth.com>
- Date: Sat, 5 Feb 2011 02:10:17 -0800
On Fri, Feb 4, 2011 at 9:00 PM, Cedric Vivier <cedricv at neonux.com> wrote: > On Sat, Feb 5, 2011 at 08:42, Adam Barth <w3c at adambarth.com> wrote: >> interface Crypto { >> ?Float32Array getRandomFloat32Array(in long length); >> ?Uint8Array getRandomUint8Array(in long length); >> }; > > I think the API would be more flexible and more future-proof defined as : > > interface Crypto { > ? ?void getRandomValues(in ArrayBufferView data); > } > > getRandomValues(in ArrayBufferView data) > Fills a typed array with a cryptographically strong sequence of random values. > The length of the array determines how many cryptographically strong > random values are produced. > > > We had same discussion when defining readPixels API in WebGL. > > Advantages : > 1) this allows to reuse the same array over and over when necessary, > or circular buffer, instead of trashing the GC with new allocations > everytime one wants new random bytes. > 2) this allows to fill any integer array directly (Float*Array might > need more specification here though as Boris pointed out - could be > disallowed initially) > 3) this avoids exposing N methods for every type and makes refactoring > simpler (changing the array type does not require changing the > function call) > > (and also better matches most existing crypto APIs in other languages > that are also given an array to fill rather than returning an array) Oh, that's very cool. Thanks. Adam
Received on Saturday, 5 February 2011 02:10:17 UTC