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).
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.
TomZ