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

[Robert]

OMG, I have had a huge brain fart. I totally forgot that plugins are built *as* shared object Libs.

So our choice to invoke said SOLib through named primitives are just as workable as somehow invoking FFI on them. What would that look like 👀? Is there an example for calling FFI, for one of the Crypto plugins? Let’s evaluate.

Kindly,
Robert

On Mon, May 25, 2020 at 12: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.
>
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20200525/2f50f038/attachment.html>