The callback on each transaction was only called when individual tx
were fetched, which is "magic" behaviour and I don't like
inconsistencies.
So, also call the callback for each transaction in a block we fetched.
This will most likely benefit some FloweeJS users when they do some stuff
that I didn't think a good idea, at least this way they will not get
a bunch of errors :)
The FloweeJS component uses this class but requires the usage
of the NodeJS 'main' thread. Which needs safe access to the jobs
list at the same time the Flowee workers need access.
Simple solution; add a mutex.
Make the UTXO search callback actually useful for more than tests.
This passes all the data we have and what the user could want to use,
also updating the receiver (bitcore-proxy).
Make the callback happen after we get the indexer status.
Additionally, fix the issue where looking up a txid that failed
would end up being recursive due to us copying the initially requested
hash. Causing it to be a duplicate (which then fails etc).
The usage of a ripe160 for bitcoin addresses in the API and in the
Indexer loses some info, specifically what kind of script it is.
Additionally not all types of scripts fit this mold. At best that means
its not future-proof.
This adds a method to the API in order to select from a Tx the hashed
outscript (thats singlehashed sha256) and refactor the address indexer
to use that instead of the ripe160 address.
The API enums broke a little, so I used the opportunity to break it a
lot and clean up the enums in order to make them more future-proof.
But, yeah, software from before this commit is protocol incompatible
with software after this commit.
This makes the service mostly self-documenting as it serves plain simple
html pages for error messages which show the end points you can use.
This adds support for the "unspent outputs for address" endpoint.
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.
When a user sends a signal SIGHUP, we parse the configs again
traditionally on Unix.
We already use this for log-configs.
This signal allows apps to get notification and reload their
own configs.
For service applications that bind to networks (currently
only indexer) this allows users to pass the address:
0.0.0.0
to bind to. The effect will be that we find all the network
interfaces in the system and bind to all of them.
Notice that we already had "localhost" as an alias to bind to both
v4 and v6 loopback interfaces.
This new feature depends on optional dependency QtNetwork.
All client apps (=connecting to a server only) now gained the verbose
and quiet command line arguments to select a different level of
verbosity.
Servers don't need this as they use a config file.
This also makes the --debug option only for debug builds as the logging
system already doesn't compile in debug statements otherwise, it makes
little sense to try to print them.
Now everyone auto-connects to localhost unless passed the
option --connect=
Also make indexer find the logs.conf from the same dir as the
commandline passed config file.
This makes running it as a service more useful.
TomZ