I did a bit of mocking up of what the refactored data_store interface for that AFIO tutorial will look like:
https://gist.github.com/ned14/163ac57c937bda61e5c9
Ok, so it's no longer the world's simplest key-value store API and I deliberately dropped the STL iostreams interop, but the big difference is that this one is real-world ready and probably quite close to a final API design for such a thing.
*Looks* much better, you seem to listen after all. I wouldn't call that to
be real-world-ready without a thorough specification of the semantics,
though.
For instance:
- What happens if commit() was called on your transaction, the returned
future is not ready yet, but the ~transaction() is called?
- Why is your transaction object not RAII?
- Why do you need begin_transaction?
- Why do you need two load_blob() functions?
- Why is your buffertype so over-specified, shouldn't any range do?
- Why can't the user specify/provide the type of the hash? std::hash<>
anybody?
- Why does one of the load_blob returns a
future