[Vm-dev] [Vm-beginners] Stability of the external plugin interface

[tim Rowledge]

OK, I'll try to answer some of the thoughts on this - 

> On 2020-05-24, at 11:07 PM, Robert <robert.withers at pm.me> wrote:
> 
> How about the CryptographyPlugins? What would switching to FFI look like? I feel like we still need custom C code implementing the algorithms. 
> 
> Is it that we would have shared object libraries (.so/DLLs), generated from slang, but not creating plugins, just generating .so libs and the FFI calls to use them? 

Right now (assuming I'm remembering it all correctly and with the proviso that I haven't written a new plugin in several years) an external plugin is compiled from the assorted code required (some plugins are solely slang generated code, some are solely hand-written C, some are slang + C + calls to other libraries and so on) and a platform specific form of shared library is made. Are they in a form that is callable via 'normal' ffi calls? Dunno, but clearly they *could* be made that way with not very much change.



> On 2020-05-24, at 11:26 PM, Tobias Pape <Das.Linux at gmx.de> wrote:
>  The effect would be that we have to
> settle on one SSL library on all platforms, and keep that updated and ship it with the VM.
> That's by the way what the Pharo VM does and I think it is the wrong way for the problem.

Actually no, that isn't how you *have* to do it. You can have interfaces from the image to many different libraries; hence the mentions of 'bridge classes' in my message. It's not much different to how we currently choose the platform appropriate class of file directory on startup.

When the interface to a subsystem changes you have to make corresponding changes *somewhere*. With current plugins we have to rewrite the relevant parts, often the hand-written C-shim stuff. In one sense that is a virtue since we can do that with 'normal' tools like edlin, and enjoy all the fun of that world of high quality IDEs (sarcasm? Moi?). If we used bridge classes to ffi calls direct to the external system then we would have to do some work in the image; now of course in general we'd all prefer that but I can imagine cases where the changed interface prevents us running the image to write the code to handle the changed interface. This is where having a way to make the system load code at startup helps.

tim
--
tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
Eagles may soar, but weasels aren't sucked into jet engines.