Re: [whatwg/streams] Communication between workers/windows via Streams API (#244)

Assuming we want chunks to be transferred where possible, rather that copied, we have three main options on the table:

### 1. **Opportunistic greedy transfer.** 
  Any part of the chunk that is transferable is transferred, everything else is copied. Example:  
  `{ name: 'carpool', value: new Uint8Array([1, 2, 3, 4]) }`
   Here `name` is copied and `value` is transferred.

 **Advantages:**
   * Easy to use

**Disadvantages:**
   * "Opportunistic greedy transfer" algorithm needs to be specified somewhere.
   * Can lead to surprising behaviour for deeply-nested objects, for example: 
    `{ thirdPartyObject: { internalThing: Uint8Array } }`
  Here the author has nested an object from third-party code inside their own object. The nested object 
  contains a transferrable field, and is unexpectedly broken by being passed as a chunk. In general 
  passing arbitrary third-party objects as chunks is not going to work well, so maybe this is okay.

### 2. **Provided by strategy.**
  An extra function is added to the strategy which provides a list of objects that are to be transferred when the stream is transferred. Example
  `strategy = { transfer(chunk) { return [chunk.value]; } }`
  would transfer the `value` property of any chunk, and copy everything else.

**Advantages:**
   * Easy to understand
   * Allows re-use of existing postMessage machinery--no extra algorithm needs to be standardised.

**Disadvantages:**
   * The `transfer()` function cannot itself be transferred, which means that if a stream is transferred twice it will lose its ability to transfer chunks.
   * Developers who want to be able to transfer arbitrary objects are going to have to write a lot of code.

### 3. **New meta-protocol.**
  Objects which are capable of being transferred contain metadata saying how to do it. Example:
  `{ name: 'fitboot', value: new Uint8Array([3,5,7]), [Symbol.transfer]: ? }`

**Advantages:**
   * A general solution which can be made to work for `postMessage()` too.

**Disadvantages:**
   * There's no way to explicitly say that the top-level object is transferable.
   * Not clear what the meta-protocol should be.
   * Probably requires the most standards and implementation work of any of the options.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/streams/issues/244#issuecomment-383458980