Open 0nkery opened 5 years ago
It's fair to say it's also unclear to me. The current code, as you can see, defaults to a pretty low amount of wrapping (e.g. sending through *c_char
instead of str
) because performance and detail-orientedness in plugins seems important and I didn't want to make any assumptions. I also definitely agree that there is a lot of room to make it easier for plugins to define the functions and deal with the callbacks provided in init
. If there were a way to provide both a low-level and high-level API in the way you suggested without duplicating a lot of code or introducing performance problems, I would be very interested.
Marshall, thank you for the answer. That's nice to see the project is still under maintenance. We'll take another look and come with some suggestions on the plugin API if that's ok.
Hi!
Thanks for helpful library!
Are there any plans to implement more higher-level and safe API? I have kind of proposal but there are many details it lacks.
Plugin
trait which defines all the callbacks user should implement in two ways: low-level (raw) and high-level. The latter operates on more idiomatic Rust entities such as references, Rust structs, strings and numeric values while the former leaves all the raw details in place allowing to skip possibly slow conversions and defaults to calling 'high-level' methods.extern "C"
functions along withstatic
declaration of user object which implementsPlugin
trait. Functions just deal with acquisition ofstatic
object and call methods on it.init
callback can be more elaborate - it can initialize callbacks to Janus Core which crate then will use to provide more high-level API for them (just regular public functions, no need to fetch globalPluginCallbacks
object and call functions there).It's unclear to me how to wrap all Janus objects from outside in more convenient and safe way.
What do you think of this?