On a Futures-style API

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.

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.

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:43:32 UTC