You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The market_history and account_history plugins use the same space ID.
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.
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).
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.
From @theoreticalbts on August 18, 2015 18:19
Currently our plugin architecture is not well encapsulated. Here are some problems I found:
operation_history_object
in the core.most_recent_op
inaccount_object
as noted in the comment here.meta_account_object
.market_history
andaccount_history
plugins use the same space ID.account_history_plugin.hpp
noting that an object ID definition applies to the market history plugin!witness_node
binary with noaccount_history_plugin
, and in fact should encourage active witnesses to run the stripped-down version without unnecessary indexes.Copied from original issue: cryptonomex/graphene#246
The text was updated successfully, but these errors were encountered: