2.0 API comments by @linse and @hannesm

(taken from #14, copied here to preserve visibility once #14 is merged) The 2.0 API just landed, and we already have some potential enhancements (for a 3.0):

~~maybe a way to specify chunks within data is handy (we used to have val read : t -> key -> off:int -> len:int), now it's an all or nothing get : t -> key -> (string, _) result io~~ (part of #28)
~~there is no longer a function size, is it sensible to have one?~~ (part of #28)
the key is atm (in mirage-kv-lwt) constrained to Mirage_kv.Key.t, some simple use cases may not need a complete path as key, but a string may be fine -- should we functorize implementations over a KEY signature
- should we abstract (functorize?) over type key / module Key in mirage-kv? This allows a user to select their key (e.g. a string, or a path, or a custom variant type), and implementations to use the module Key interface. The path key implemented here by module Key, a flat string key should be provided by mirage-kv. is using a string as key a special case of the path (using a single segment path) -- or does this imply computational overhead (need benchmarks!)?
the value is of type string, we may want to use proper (arbitrary? GADT?) types and marshal to/from string (using e.g. sexp)
should the KV interface implement the OCaml Stdlib Map.S interface?
documentation:
- what is the definition of structured and why is it relevant here?
- why do we have nested dictionaries?
- include some information whether this library also works when we have no nested dictionaries (flat kv store)? does it perform well? do we recommend something else?
- mention that the V of KV is always a string. we should write that explicitly.
Key module:
- why v? value? this confuses me in the scope of a key-value interface, where the key has a function named value. maybe of_string is a better name
see as well more discussion in https://github.com/mirage/mirage-fs/issues/20

mirage / mirage-kv

2.0 API comments by @linse and @hannesm #16