Clean up plugin architecture

[vikramrajkumar]

From @theoreticalbts on August 18, 2015 18:19

Currently our plugin architecture is not well encapsulated. Here are some problems I found:

• [ ] We have code like this that manipulates operation_history_object in the core.
• [ ] There is no reason to have most_recent_op in account_object as noted in the comment here.
• [ ] The annotation subsystem is undocumented, unused and untested, but there are vestigial remnants of an early architecture where it was more widely used, such as meta_account_object.
• [x] The market_history and account_history plugins use the same space ID.
• [x] There is a comment in account_history_plugin.hpp noting that an object ID definition applies to the market history plugin!
• [ ] The build scripts contain no provision for compile-time disabling of plugins. We should be able to build a witness_node binary with no account_history_plugin, and in fact should encourage active witnesses to run the stripped-down version without unnecessary indexes.
• [ ] The CLI parameters contain no provision for run-time disabling of plugins. You should be able to specify which plugins you want in a config file, to enable/disable plugins without having to recompile.

Copied from original issue: cryptonomex/graphene#246

[vikramrajkumar]

From @bytemaster on August 18, 2015 18:22

While I agree that it would be nice to clean this up. Do not assign items to yourself that you will not be working on this week. This is low priority.

[vikramrajkumar]

From @theoreticalbts on March 3, 2016 18:26

One of the problems with FC's API implementation is that it's not possible to get a "black box" API. For example, to implement this ticket, we would want a method get_api( string api_name ) which should check that the user's authorized to access the API given in the config file, but the implementation of this method need not be aware of the details of API methods. But the only way to refer to an API is through fc::api<T>. So fc::api needs an abstract superclass which has the "generic" API stuff (e.g. working with handles and having an entry point for calling a method with string name and vector<variant> args).

[vikramrajkumar]

From @theoreticalbts on March 3, 2016 19:1

In addition, it would be nice if a plugin could introduce new wallet commands in addition to new API calls. Perhaps a syntax plugin_name.command_name could be used in the wallet to access plugin-provided commands, and perhaps via configuration you could dump some plugins into the global "namespace" making their commands accessible without a dot.