Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Plugins depending on other plugins #35

Open
flavius opened this issue May 10, 2020 · 1 comment
Open

Plugins depending on other plugins #35

flavius opened this issue May 10, 2020 · 1 comment

Comments

@flavius
Copy link

flavius commented May 10, 2020

At first sight this crate does many things I've tried to accomplish in the past 2 years in my free time, so thank you for that.

Before I dig in further, I wanted to ask if, in a plugin system, any if the plugins can get as dependency any other plugins?

Of course:

  • I would have to ensure in my application that there are no dependency cycles in the graph
  • I would need to construct my plugins in two stages, one in which they can advertise "their handle" (akin to TypeId) and a list of handles that they depend on, and the second stage in which I sort topologically the dependency graph and actually start each plugin with all the dependencies they need

If not currently possible, do you see this as a possible feature which can be planned in? Would it be before 1.0.0 or after that?

@rodrimati1992
Copy link
Owner

Don't think that abi_stable needs to explicitly support this for it to be doable.

You could define a function to query the dependencies of a plugin, then load them, and once you've loaded all of them initialize them by passing the list of trait objects for the plugins that they depend on,starting with the ones that don't depend on any plugins.
I'd imagine that the dynamic library functions would be something like

extern fn get_dependencies()->RSlice<'static,Dependency>;
extern fn initialize(plugins: RSlice<'static,Plugin>)->Plugin;

Plugin being a type alias for a static "trait object"(not dyn Trait,a struct that the #[sabi_trait] attribute macro generates),for a trait you declare in the same crate as the types shared by all plugins.

I don't know how unique identifiers for plugins would work though,in my example I simply use the path to the plugin.

Internals thread related

Now separate from the things you've mentioned in this issue,I don't know how these things you mentioned in the internals thread would be done:

  • The ability to inspect what traits are implemented by the plugin, and call them
  • Generic functions

I don't have a clue where to start with those,and won't consider anything that requires a non-trivial amount of effort to support.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants