Configuration of node plugin options

[braydonf]

Versions bcoin v1.0.2

Expected

Ability to configure plugin options without env work around for the name space to be recognized.

Actual

It's necessary to use:

const node = new FullNode({
  plugins: [require('../../lib/wallet/plugin')],
  env: {
    'BCOIN_WALLET_HTTP_PORT': '49333'
  }
});

Option A

const node = new FullNode({
  plugins: [require('../../lib/wallet/plugin')({
    httpPort: 49333
  })]
});

Pass the options directly to the plugin before it's given to the full node.

Option B

const node = new FullNode({
  plugins: [require('../lib/wallet/plugin')],
  pluginOptions: {
    walletHTTPPort: 49333
  }
});

Provide a specific key that handles all plugin options that would handle the plugin namespace prefixes, as described in https://github.com/bcoin-org/bcoin/pull/562

Option C

const node = new FullNode({
  plugins: [require('../lib/wallet/plugin')],
  walletHTTPPort: 49333
});

Have all of the full node options parsed to handle the plugin prefixes, for example anything that starts with wallet would be recognized as a wallet option.

[tynes]

I like Option A the most because all plugins shouldn't have access to all of the configuration options. It would mean that the interface to a plugin changes, but its possible to check the type of the plugin to determine if it is using the function interface or the object interface.

Option B seems like it wouldn't be difficult to implement, and would only require changes to bcoin, but then all plugins would know any secrets associated with a specific plugin. I think a popular plugin could be a SQL DB indexer, and we shouldn't allow another plugin that can arbitrarily execute code have access to the DB secrets.

Option C seems like a natural extension of whats already available in bcfg since it has the prefixing logic with environment variables. The dev then needs to go look inside the plugin to learn what its name is to be able to configure it and things would break if the names changed. That could work, but I don't think its as nice as Option A.

My vote is Option A since bcoin v2.0.0 will have breaking changes anyways and we can do it in a non breaking way if we are careful

[braydonf]

I think there are also several issues with plugins in general that make them not very usable in practice.

In regards to the wallet, it may be preferable to consider it a separate process and application as the default in regards to configuration, as that is how it's handled with a separate configuration file.

It may be possible to resolve this also by separating the wallet in the tests, and etc, in which case it will most resembled Option A, as you have mentioned.