You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I think it’s a good idea to split host API and plug-in API compatibility like this and version them separately. the plug-in compatibility is gonna be the real bear, because releasing a new version of your extism-using product will break all existing plugins if it versions up the runtime to a plug-in breaking version, which is a shame. The host SDK and runtime compatibility are almost not an issue since it’s all on the developer side (but nice to think about them anyway :)) . If you’re not careful though you could easily get into the Python 2 to 3 situation on the PDK side.
One thing you could consider is how the plug-in API could be designed to have escape hatches so future runtimes could emulate compatibility and keep older versions working if they desired. eg. If I could have a blue-oyster that’s latest of all versions, but I could have a (probably bigger, slower) version like blue-oyster_barnacle that supported 2 pdk versions, I would definitely use that. That would let greenfield apps choose not to support legacy plugin coding models, but brownfield could keep running some backwards-compatible version.
An example from the Python 2 to 3 was converting print from a statement to a function (print “a” vs print(“a”). From a language design perspective they wanted to make this change. However, it wasn’t truly breaking - they could have supported both forms if they really wanted to, or allow the runtime to run in a “compatibility mode”. I do think this should be opt-in though, not required for all users.
You could also introduce a layer of indirection and develop the code as requested capabilities and supported capabilities instead (taking your example from 2 to n). Then each logical area of the code could be its own version - like when cancellable plugins were introduced. Then the PDK can just suggest to the runtime which capabilities it needs, instead of hardcoding the comparison to the color-creature combo.
That would have a benefit too that you could not even require upgrades of plugins that didn’t make use of capabilities that had breaking changes
I think your solution is probably sufficient or close though, just throwing some ideas out
The text was updated successfully, but these errors were encountered:
I think it’s a good idea to split host API and plug-in API compatibility like this and version them separately. the plug-in compatibility is gonna be the real bear, because releasing a new version of your extism-using product will break all existing plugins if it versions up the runtime to a plug-in breaking version, which is a shame. The host SDK and runtime compatibility are almost not an issue since it’s all on the developer side (but nice to think about them anyway :)) . If you’re not careful though you could easily get into the Python 2 to 3 situation on the PDK side.
One thing you could consider is how the plug-in API could be designed to have escape hatches so future runtimes could emulate compatibility and keep older versions working if they desired. eg. If I could have a blue-oyster that’s latest of all versions, but I could have a (probably bigger, slower) version like blue-oyster_barnacle that supported 2 pdk versions, I would definitely use that. That would let greenfield apps choose not to support legacy plugin coding models, but brownfield could keep running some backwards-compatible version.
An example from the Python 2 to 3 was converting print from a statement to a function (print “a” vs print(“a”). From a language design perspective they wanted to make this change. However, it wasn’t truly breaking - they could have supported both forms if they really wanted to, or allow the runtime to run in a “compatibility mode”. I do think this should be opt-in though, not required for all users.
You could also introduce a layer of indirection and develop the code as requested capabilities and supported capabilities instead (taking your example from 2 to n). Then each logical area of the code could be its own version - like when cancellable plugins were introduced. Then the PDK can just suggest to the runtime which capabilities it needs, instead of hardcoding the comparison to the color-creature combo.
That would have a benefit too that you could not even require upgrades of plugins that didn’t make use of capabilities that had breaking changes
I think your solution is probably sufficient or close though, just throwing some ideas out
The text was updated successfully, but these errors were encountered: