Re: On a Futures-style API

On Tue, Apr 23, 2013 at 10:43 AM, Richard Barnes <rbarnes@bbn.com> wrote:
> As it happens, I did some thinking about what a Futures-style version of the API would look like.
>
> One key difference is that a Future represents the output of the function.  Instead of the callback getting a reference to the Operation (as event.target), it gets a new output object.  So we need to define what these outputs are.

The DOM Futures output still has a .result - it behaves the same as
CryptoOperation.result / KeyOperation.result

We already have defined what these outputs are.

A sample reworking of the WD is at
https://github.com/slightlyoff/DOMFuture/blob/master/reworked_APIs/WebCrytpo/after.idl

>
> It seems to me that there are three high-level types of output:
>
> 1. Ciphertexts (from encrypt / sign / digest): These objects need to have the output of the cryptographic process (the ciphertext data itself), as well as references to the parameters used to generate it.  That is, the algorithm/key fields that are on CryptoOperation today.

In the above example, CryptoOperation is-a Future, and thus in
addition to .result, can still expose the additional properties -
along with methods for chaining (in addition to the future methods
like .then() and etc)

>
> 2. Plaintexts (from decrypt / verify)
>
> 3. Keys (from generateKey, etc.)
>
> This taxonomy also provides kind of a nice structure for the various API methods.  Namely, the methods convert from one of these types to another.  So the primary input to the method is an object of the source type (e.g., a plaintext or ciphertext), and everything else is configuration for the conversion.
>
> I've put together some notional IDL to sketch out how these concepts could turn into an API:
> <https://docs.google.com/document/d/189K7BFE9jmNHyEerc5qac0T5l454WcC_v5tkFmjGpL4/edit?usp=sharing>
>
> Hope this helps,
> --Richard

Received on Tuesday, 23 April 2013 17:50:39 UTC