NODE_EXT_SERVICE: Advertise other services also available at this node. #4657
Conversation
There was a problem hiding this comment.
Can you at least try to respect the coding style rules we have (include ordering etc.)?
There was a problem hiding this comment.
If this continues to produce hectoring, then the most appropriate action is to remove that rule from doc/coding.md. At some point you need to ask yourself whether this is satisfying your personal OCD versus making the bitcoin project and its developers more (or less!) productive.
There was a problem hiding this comment.
@Diapolo is quite right to point this out if it goes against coding standards and @jgarzik is quite right to point out that the coding standards may need revising.
May I take this moment to suggest reading the "four agreements"? (http://crossfitcetro.com/wp-content/uploads/2012/08/the_four_agreements.jpg) - I'm seeing all too often people taking things a bit too personally on here, however, it could almost go without saying that I for one am grateful to @jgarzik for so many of the code changes he's contributed, and I hope other user's sterling efforts (OCD fuelled or not) to enforce style rules don't deter future contributions.
There was a problem hiding this comment.
It makes sense to have a well-defined coarse include order. I.e. first your own include, then dependencies within the project, then dependencies outside the project. This makes sure that the compiler checks that your own include file (in this case extservices.h) includes everything it needs on its own.
As for alphabetical sorting, it could be argued that that is a step too far, although if you want to define some fixed ordering within the groups alphabetical makes most sense. For example it makes it easier to see duplicates.
|
Automatic sanity-testing: PASSED, see http://jenkins.bluematt.me/pull-tester/p4657_ee3274f94d94833efe364346d2c74d8be6a18a83/ for binaries and test log. |
|
I'd recommend using uint16 for the port instead of int32. You can use 0 for "invalid". A port has always been uint16, and making it int32 just seems odd. |
|
How is the process side of this moving forward? I know it has been discussed on the mailing list on some point, but I think it still needs e.g. a BIP number. |
|
Closing for now, as no active development is happening on this. |
6 participants
It is not necessary to build all functionality into bitcoind, to form a decentralized network. BitPay's insight open source block explorer API project requires, and runs on top of, bitcoind. Therefore, at the same IP address as bitcoind, other services are made available to the public (scriptPubkey queries, other added-value queries). This results in a decentralized network of "anyone running a full node and an insight server", as a subset of the whole P2P net. </vendor hat>
Obviously, we want to build this in a generic, vendor-neutral way.
Services may only advertise added services if and only if the external services are at the same IP address that is being advertised.