Subject: Re: [boost] [AFIO] Review (or lack of it)
From: Hartmut Kaiser (hartmut.kaiser_at_[hidden])
Date: 2015-08-30 11:19:12
> I did a bit of mocking up of what the refactored data_store interface
> for that AFIO tutorial will look like:
> 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,
- 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<>
- Why does one of the load_blob returns a
future<std::shared_ptr<buffers_type>>? Handle to handle to handle to data
this time? Shared ownership again, really?
- Can this blob-store be distributed over many machines? Can it be in memory
only (with transparent disk backup if needed)?
- Why do you specify undefined behavior into your API (see your union). Why
do you need this in the first place?
- What's the concurrency/thread-safety guarantees of each of the functions?
etc. many more open questions remain. Please, don't get me wrong, I don't
need/want answers to those questions right away, I'm just listing those for
you to think about.
I however suggest that you redesign AFIO first (including the proposed AFIO
API), before you even start thinking about submitting this to Boost review.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk