The only feature that’s still missing from the current version of the lv2 crate is support for extension data.
First of, what is “extension data”? Some specifications require new callback functions from the plugin; A prime example is the State specification, the standard way to safe and restore the state of a plugin. To support this specification, a plugin has to implement a “save” function and a “restore” function that, obviously, save and restore the state of the plugin. Somehow, pointers to these functions have to get to the host and this is where extension data becomes important:
From a host’s point of view, every plugin implements a function called “extension_data” which receives a pointer to a URI and returns a pointer. In the case of the State specification, this function should return a struct containing pointers to the save and restore functions when “extension_data” is called with the appropriate URI. However, matching the strings, creating the pointer struct and returning it involves a lot of boiler-plate code and is therefore a candidate for abstractions. This is the thread where we can discuss these abstractions.
I guess, from the user’s/plugin programmer’s point of view, it would be ideal to only implement a trait and not to do much more. Although I think that founding this feature on trait implementations, this is far from enough to do the job: Somehow, the “extension_data” method has to know of these traits as well as their implementations and export them.
How could we do this? I would personally prefer “normal” methods over solutions involving macros, but if macros provide the most convenient design, I would agree to them too.