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

Tobias Pape Das.Linux at gmx.de
Mon May 25 17:16:02 UTC 2020


> On 25.05.2020, at 18:46, tim Rowledge <tim at rowledge.org> wrote:
> 
> 
> 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.

Per se, true. But try discriminating openssl 0.9.6, 1.0.1, and 1.1.1. It's a nightmare. The overlay somewhat works, but even that is not so easy.

It's just that I've seen the bridge-class stuff made things hard for me in Self.
But that might just be the long time gap where X11 evolved and the Self part did not. Problem was I had no tools because I broke my tools with my tools (so to speak, because no UI, no way of fixing the UI properly).


> 
> 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?).

Not that I like digging in C more than using Squeak proper...

> 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.


Again, FFI is fine. My point is rather that the pace of change can indicate whether a plugin is better or FFI.

Also, the other VM-implementations can provide Plugins much more easily than FFI.
I would argue this is true for SqueakJS, RSqueak, JSqueak/Potato, and to an extend, TruffleSqueak.
These systems do not necessarily provide access to C libraries and reduce the need for in-image changes for each VM.


TL;DR: FFI good, Plugins also good.

just my 2ct.

Best regards
	-Tobias






More information about the Vm-dev mailing list