SeaFox wrote: ↑
06 Oct 2018, 23:38
No it's not. Because the purpose of sandboxing is to protect your computer from malware.
That's only one (actually small) facet. And while it's certainly an issue to take seriously, there are more issues than that. To go over it again:
When you have native code, it can rely on whatever it wants from the system. Make a call to CoCreateInstance, and suddenly it's Windows-only, and no Linux, Mac, or Android system can use the plugin. Make some DX12 call, and it's Windows 10-only, no Win7 or Win8 support. Such plugins would be distributed as shared libraries, which inherently embed platform-specific data and code, meaning even if you personally don't make any system-specific calls, you still have to build and provide multiple shared libs, one for each platform you want to support. You can also look forward to different CPUs. A plugin for 32-bit OpenMW and a plugin for 64-bit OpenMW, for each supported OS. Then you can look forward to different CPUs, some OSs supporting ARM (32-bit and 64-bit flavors).
With sandboxed-only code, we can ensure a script that works on one system can work on the others, no extra work on anyone's part to support. The same mod and same code would work everywhere. But as many other projects have shown, most people have a habit of just targeting the system they use which is likely also the most widely used, because it's easier to use what they're already familiar with (for most developers, non-portable Windows code) than to look for or request something new. So even though there are people using other systems, they'd be locked out from using those mods.
When the engine oversees everything a mod does, it can ensure correctness, warn of and workaround problems, and just generally handle errors gracefully. When a mod can call out to native code, the engine has no say in anything that goes on. The mod may work 95% of the time, so it's not a deal breaker but has an annoying tic. Add another mod that also works 95% of the time, and another. Then people complain how the engine is so unstable, while the engine can't do anything to fix the problems because it has no control over what those mods are doing.
Make a non-sandboxed plugin now, you can obviously only target systems that exist now because you can only build for systems that exist. When mods only use sandboxed code, any platform OpenMW itself can be ported to in the future will automatically inherit all existing mods. Even if the modder is long-gone, no changes are needed to the mod to support new systems.
Systems aren't static, and code is not always bug-free. It's not hard to find cases where some code works while inadvertently relying on a bug or undefined behavior in the system. The system updates, and even though neither OpenMW or the mod changed, the plugin stops working because the undefined behavior changed. With sandboxed code, only OpenMW is responsible for ensuring the plugin works, so if a mod stops working, we can pinpoint what in OpenMW changed to make it stop working, and provide a built-in fix or some other workaround.
So 20 years down the line, when you want to revisit that old mod you remembered having a lot of fun with, you can be relatively sure it'll work regardless of all the system and engine updates that've occurred since the mod was last updated. And if there is an issue with the mod, you can report it to whoever's working on the engine to get it fixed and make it work again.
Or if you're getting fed up with whatever OS you're currently on, you don't have to be concerned about your mods being compatible with other platforms you're thinking about changing to.
Or if you hear about an awesome new mod coming out, you don't have to wonder if it'll support your system.