|
Title: Adding more details to JSON-RPC method output Post by: Luke-Jr on October 05, 2011, 04:08:42 PM Link to pull request (https://github.com/bitcoin/bitcoin/pull/556#issuecomment-2298468)
These changes are 100% backward compatible. Adds to "getinfo" output: "pooledtx" (number of transactions in memory pool), "currentblocktx" (number of txns in the last block created), and "currentblocksize" Adds to "listtransactions" and similar output: "block_hash" and "block_index" Title: Re: Adding more details to JSON-RPC method output Post by: Luke-Jr on October 30, 2011, 11:43:42 PM Bump.
Title: Re: Adding more details to JSON-RPC method output Post by: John Tobey on October 31, 2011, 03:37:00 AM Luke-Jr, thanks for the patch.
Assuming it is bug free (which I'm not sure... does it mutex the reads of shared data like nPooledTx?) my concern is code bloat for a feature with a dozen(?) potential users. Not to say the code base isn't currently bloated, ;D but now seems a good time to mention refactoring options. Imagine compile-time options similar to -DUSE_UPNP and -DGUI controlling inclusion of esoteric features. (I note that optional features should in no way affect the validation rules, since we want everyone to agree on those.) Luke's features, and probably over half the existing RPC cruft, could go in a separate file, ideally behind a module interface such as VinceD's hooks. Imagine "extensions.cpp" defining CExtension extensions[], each element's existence controlled by an #ifdef, and each CExtension implementing a bunch of hooks, one of which the RPC table constructor would call and allow to insert methods. Anyone? Title: Re: Adding more details to JSON-RPC method output Post by: Luke-Jr on October 31, 2011, 03:52:10 AM This shouldn't add any overhead, and I'm assuming mere integer read/set doesn't need a mutex to be safe-- you either see the value before or after the change.
Title: Re: Adding more details to JSON-RPC method output Post by: John Tobey on October 31, 2011, 04:12:18 AM This shouldn't add any overhead Oh, the runtime CPU and memory cost would be tiny, I'm sure. But now, as a code reader, I must scan past three new globals to see the meatier parts such as pindexBest right above them. It's not that I don't like the feature, or even (maybe) enabling it by default, but adding things in this way gradually makes the program harder to understand. I'm assuming mere integer read/set doesn't need a mutex to be safe-- you either see the value before or after the change. Even for uint64 on 32-bit systems? And what if parts of the same getinfo result reflect changes that other parts don't reflect? |