Our current implementation passes a numpy reduction all the way down into the reduce_chunk method, which we expect to be implemented in storage. That argument needs to be a value from an enumeration (or an integer representing the index of the value in the list).

We need to pull the enumeration out into something visible to implementors, and push the enum value through the API, and reintroduce the numpy reduction in our python implementation of reduce_chunk.

We should also be clear about what we expect to be returned from each of these operations.

At the same time we should be clear about what our expectations are on the storage, we are starting to have several possible versions of active storage to consider:

• vanilla (no missing data support, conforming to the minimal enum),
• missing (with missing data support, conforming to whatever we decide in Multiple operations instead of means #33),
  • with or without the chained method support (if we think that is a good idea)
• compressed (will need support for the simplest implementations of compression)
  • with or without
• compressed and filtered (will need support for some of the simplest filters associated with some compression methods)

Perhaps we should have a way of interrogating active storage to find out which of these it has implemented?