search

PistonDevelopers / inventory

DEPRECATED - Plugin management for Rust programs
MIT License
0 stars 0 forks source link

Project structure #1

Open fenhl opened 9 years ago

fenhl commented 9 years ago

The purpose of this project is to enable Rust binaries to support the addition of plugins. There are three perspectives to be considered here:

  1. The core project needs an interface through which communication with plugins occurs.
  2. Plugins should be able to test their code against the core.
  3. Users need a tool which compiles plugins into the program, ideally with no prior knowledge.

This project should cover all three. So how do we structure it to provide this functionality?

bvssvni commented 9 years ago

@Kingsquee has a setup for compiling and linking dlls at runtime https://github.com/Kingsquee/Worldsong. Perhaps use some of his ideas?

fenhl commented 9 years ago

That's GPL.

ghost commented 9 years ago

go for it

bvssvni commented 9 years ago

@Kingsquee beautiful

ghost commented 9 years ago

In all seriousness, while Worldsong has state-preserving runtime loading, It seems to be in contrast to just about every other point of interest:

1) It's an API-less framework that defines the project structure, but otherwise gets out of the way. 2) An eye toward flexible compilation: Should the whole project be a collection of libraries, or compiled into a single executable? Should plugins be treated as dylibs, rlibs, or (soon™)modules? Should we run LTO or not?

If it is compiled as a collection of libraries, it should:

3) Be very easy for anyone who understands the basics of programming to modify/mangle/hilariously mutilate the end application. 4) Support (eventually automated) addition / removal of packages of functionality without sacrificing mod flexibility. This comes at the cost of an author occasionally needing to manually add process-order metadata to a package to avoid conflicts with others executing at the exact same location in a schedule, or (at worst) the person installing the mod to push its process call(s) up or down in a schedule themselves.

In context of the last two goals, perhaps now the GPL makes a bit more sense. In my target use-case, throwing un-diffable third-party source-less version-locked DLLs around isn't beneficial for a modding community.

So I'm not sure how much inspiration it can be!

fenhl commented 9 years ago

Without knowing much about how dylibs/rlibs work, my approach to compilation would be moving all the plugins into a submodule and running codegen for by-name and iterator access, then letting Cargo compile the whole thing.

bvssvni commented 8 years ago

One idea: Can the current library can be used to share data between the application and the plugin?