This improves the double spend proof orphans code.
Also add a DSProof log-category and lots of log lines to make
looking at a debug build much more fun.
The core APIs in Flowee are quite low-level and especially combining
results from multiple services becomes tedius, verbose and thus
error-prone.
For this reason I wrote a new SearchEngine and related classes which
allow one to create a single compound request, submit it to the engine and
get a callback when it is done.
For instance one can now create a request for a transaction by txid and the
system will split this into a txid-lookup and the actual fetch for the
transaction.
Enough callbacks and options exist to be able to add a lot more details
this way in a simple manner.
Move some methods about arguments from util.cpp to Logger.
This makes the logger more stand-alone and this avoids the
global defined in util.h (still to be fixed in future..)
This adds lots of little things;
* Add GetTransaction API call
* I refactored the GetBlock API a little to reuse code.
* a new 'Version' API call for the hub
* API for the logging manager, so we can set a default
setup with just C++-APIs
* various (usability) fixes in the FloweeServiceApplication
* Binding to localhost attempts to bind to both IPv4 and v6
* Print the actual transaction hex from indexer-cli (which really
is just a testing app)
The old was based on levelDB which has scalability issues and stability
issues. (most often cited problem is corrupted database..)
This unspent output database I wrote is based on the idea that we need
never actually update any rows, which makes most old fashioned databases
a bad fit.
All we do is create rows and we forget rows. So lets design a DB to fit
that pattern.
* logs.conf now also found directly in the homedir if there is no
$HOME/.config dir
* default filename is now 'hub.log' instead of 'debug.log'
* logs.conf now also detects ALL as a keyword for section
* logs.conf now also supports 'option path [path]'
To allow configurability, don't give the whole 1000 sections a
real component, let them be a meta-group.
Also add the upcoming POS (point of sale) component.
The change signifies that the server is not just for admin purposes it
will become the preferred way for all subnet-local interactions.
Notice that we still have the JSON based RPC protocol as fallback.
TomZ