search

maelh / hxd-plugin-framework

Plugin framework for HxD's data inspector
Mozilla Public License 2.0
166 stars 22 forks source link

[Suggestion] Add a `Version()` function to the framework #4

Open exodustx0 opened 2 years ago

exodustx0 commented 2 years ago

The changes introduced by commits 1fd3ef0/05ccf3e and c3abba5/86afeb6 include breaking changes of existing APIs. This means that, when a new version of HxD is released that incorporates these new additions in the plugin framework, old plugins will have undefined behaviour. Unless there's a way to check the format of arguments that a DLL's function expects,

I suggest adding a Version() function to the framework which would report to HxD what version of the framework a plugin targets. From there, if a loaded plugin reports an unexpected target version, HxD can either adapt to the plugin (if it targets an older version) or reject it, to prevent a plugin from misconfiguring itself, crashing, or producing some other undefined behaviour.

Though I will note, in the event that you won't have HxD adapt to plugins targeting older versions of the API, I'd highly encourage you to instead incorporate changes to existing APIs in new functions, so old plugins will always keep working without any surprises or requiring additional work.

maelh commented 2 years ago

Right now every plugin is expected to be adapted to each new release, which is why the framework is tagged with version numbers. The changes so far have been minimal, and adding extra code paths to HxD would be counterproductive, since usually ABI changes are meant to improve the code/cleanliness/correctness.

Adding versioning information that is checked automatically makes sense and was mentioned briefly in this pull request: https://github.com/maelh/hxd-plugin-framework/pull/2#pullrequestreview-943891351

If this commit is meant to create ABI stability, then I am afraid to say it won't change much, since it may likely break with new releases as I favor strong type safety over unchanging ABIs.

Versioning should be introduced though, to remind people of updating the interfaces, by requiring to pick the right ABI version, which will be checked upon loading the plugin.

Maybe I could use a checksum of the interface, a bit like it happens in ROS, which minimizes and standardizes interface definition code, and checksums it to generate a unique ID.

The ROS approach would be the best, as introducing manually managed version numbers would mean to really keep track of every little change in the function prototypes and be sure to never forget to update version numbers.

After writing a tool that creates a checksum out of a minimized and standardized interface file (the original/base version will always be in Delphi/Pascal), the versioning process would be automated. The translation to other languages would not be automated, however.

I think that's a good enough compromise between reliability and effort.