maelh / hxd-plugin-framework

Plugin framework for HxD's data inspector

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

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

exodustx0 opened this issue · comments

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.

commented

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:
#2 (review)

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.