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
This commit adds support for enabling and disabling plugins by name.
The changes are made generically in the `PluginInstances` class, but
currently we only expose the ability to SystemRuntime plugins. Other
plugins types can be added easily.
We had a few design goals for how disabled plugins should work
1. Plugins that are disabled should still be visible to the system.
This allows us to dynamically enable and disable plugins
and report their state to the user.
2. Plugin order should be stable across disable and enable changes.
We want avoid changing the order of plugin lookup. When a plugin
is re-enabled it should return to its original slot in the
creation order.
3. Disabled plugins should not appear in PluginManager operations.
Clients should be able to assume that only enabled plugins will
be returned from the PluginManager.
We explored two other ways to implement this change:
1. Keep two separate lists and move the instances between them when
enabling and disabling plugins. This requires maintaining the
original insert order to satisfy the goals above and thus adds
some complexity to the code.
2. Return a copy of the instances list with disabled plugins removed
when clients iterate over them. This requires extra copies and
would potentially lead to the copies getting out of sync with
the actual stored instances because any modifications to the
instances would be lost.
Instead, we modify the plugin instance to maintain a bool of its enabled
state. Clients external to Instances class expect to iterate over only
enabled instance so we skip over disabed instances in the query and
snapshot apis. This way the client does not have to manually check which
instances are enabled.
0 commit comments