Re: On a Futures-style API

So maybe I'm not understanding.  In the Futures spec, I see:
"""
A resolver's accept algorithm takes a value and optionally a synchronous flag, and runs these steps:
...
• If the synchronous flag is set, process future's resolve callbacks with value.
"""

Are you saying that the value in this case is the CryptoOperation itself?



On Apr 23, 2013, at 10:50 AM, Ryan Sleevi <sleevi@google.com> wrote:

> 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 18:18:01 UTC