PS:
bitcoin-cli is untouched for now. As discussed on IRC it could be possible to have something like bitcoin-cli -w getnewaddress (-w stands for --wallet which would send the commands to /wallet). Unclear for now is how it would handle json type conversion (minor issue IMO).

I thought about this long ago.

JSON-RPC is really built around a single endpoint through which all information is exchanged. It's essentially a messaging tunnel. This PR changes that model, without apparent need.

It did not seem to make sense to add another level like this, when you can easily just add new methods. Convention "mining.$name" or "wallet.$name" can easily suffice, and registered services/plugins may be triggered there.

Recently there was a discussion on IRC about this topic (gmaxwell, sipa, wumpus) http://bitcoinstats.com/irc/bitcoin-dev/logs/2015/04/10#l1428649319
It came out that a new url endpoint makes most sense.

The signaling in this PR hooks in after the JSON Parsing and before the JSONReply. It basically allows bypassing of the raw RPC function and will reuse the whole HTTP/RPC/JSON stack.

@jgarzik Right, that's also direction I assumed we'd go in for namespacing, but @gmaxwell was arguing against that approach on IRC recently and preferred multiple endpoints.

An argument for multiple endpoints is that it makes it easier to transition to separate processes, as client software would support different URIs already.

Multiple endpoints probably also makes having different authentication easier?

@sipa Yes. If requests are delegated based on base URI, different endpoints can handle authentication differently.

Slightly updated:

• reduced to only one signal (ExtCmdExecute)
• removed signaling while creating help message (not required when having a different entry point uri)
• additional uri schemas can be added over a static function instead over signaling (while RPC server is not running to avoid locking)

Hmm, I'd rather see a single mechanism, where registered modules register for a particular URI - whether that is the root or not?

I agree with @sipa. My goal with this PR was to not touch the current wallet implementation. Therefor i only allowed/added the signaling in non root URI spaces, in hope to get more reviews because its behavior is more save and understandable.

If – and i tried and will try again – the current wallet will become a module, we should completely modularize the JSON RPC request/response handling.
But because most PR has lack of review and attention, i decided to leave the current implementation as untouched as possible and add a 2nd wallet where we have the freedom of experimenting.

Decoupling the PRC dispatch table would also be a option but looks after no interest:

• [Refactor] decouple wallet rpc commands #5934
• [Modularization] add possibility to extend or overwrite RPC calls #5744

There is also a commit who would modularize the whole wallet:

• jonasschnelli@15ccf47 (except RPC, see PR links above).

I know it somehow looks silly to add changes where there is already the plan (sometime already some code!) to change the changes. But in terms of sane change transitions and reviewability this can make sense.

Since consensus seems inclined towards integrating plugin/registration at the URI level, concept ACK

Rebased and added proper locking for vExtURI.

ut ACK

With the current libevent httpd this does no longer work and requires a new concept. Closing for now.