Best practice to give plugin writers a consistent init API?

[alshdavid]

My host application consumes plugins, importing the plugin structure from the dynamically loaded library asking, initializing it within the host application before later accessing values from it.

The host needs to accept a trait because it cannot know the underlying structure (ya know, it's a plugin).

I have been trying to use a function that returns a struct as a boxed trait like so:

#[stabby::export]
pub extern "C" fn init_plugin() -> Box<dyn AppPluginInterface> {
  // ...
  return Box::new(plugin) as Box<AppPluginInterface>
}

However this doesn't work because my type does not satisfy IStable.

Using Rust's unstable ABI directly, I have managed to get this pattern working - though it required double boxing the trait and fooling around a bit - obviously it still isn't practical given no one could write plugins for my application without matching my compiler toolchain.

With stabby, am I looking at this wrong? Rather than exporting a trait, should I export several functions and package them up into a struct on either side?

// plugin.rs

pub extern "C" fn init(base: usize) {
  // How would you handle state?
}

pub extern "C" fn add(a: uszie, b: uszie) -> usize {
  a + b
  // How would you handle state?
  // a + b + self.base
}

[p-avital]

Hi there,

The trait object approach is definitely the right way to go IMO (once you've established that IPC plugins aren't gonna cut it for you, I'd still recommend using IPC plugins if plugins aren't a bottleneck for your application).

I'm going to write direct help for your situation below, but I'd appreciate it if you read this tutorial I've written this week and gave me some feedback on it. If the tutorial isn't enough for you to get unstuck, that means I have some more work to put into it :)

IStable isn't implemented your standard boxed trait for 2 reasons:

• I assume you're using a standard Box, which isn't ABI-stable on account of the fact that its allocator (the global one) is susceptible to change between 2 binaries. stabby::boxed::Box is the proper replacement for it :)
• Even if the standard box was ABI-stable Box<dyn Trait> wouldn't be because:
  • A Box<dyn> is actually 2 non-null pointers in a trench coat: one pointing at the data (same address as the original typed Box) and the other pointing to a structure containing function pointers for each of the trait's methods (we call this a difficulty tweak vtable); but which of them is the head and which is the legs isn't guaranteed
  • the order of the methods in the vtable isn't guaranteed either

But stabby can generate stable vtables if you mark your trait with #[stabby::stabby] (prefer #[stabby::stabby(checked)] if your trait never refers to trait objects of itself); and stabby::dynptr!(Box<dyn Trait>) (assuming you did use stabby::boxed::Box) will convert the usual trait object syntax to stabby's representation of it.

Final comment, I'd advise giving your plugins a way to fail constructing by returning a Result (stabby also has an ABI stable equivalent) rather than a straight trait object :)