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

[Jakob Reschke]

Tobias Pape <Das.Linux at gmx.de> schrieb am Mo., 25. Mai 2020, 14:03:

>
>
> > On 25.05.2020, at 13:34, Jakob Reschke <forums.jakob at resfarm.de> wrote:
> >
> >
> >
> > Tobias Pape <Das.Linux at gmx.de> schrieb am Mo., 25. Mai 2020, 08:26:
> >
> >
> > This all boils down to "who moves faster".
> >
> > Here's a story.
> >
> > When I tried to get the Self VM running again some years ago, one of the
> agonizing parts was its
> > extensive use of FFI. Why so? Well, the FFI was coded against a mid-1990
> X11. Which, in that form
> > did not exist on either Mac nor Linux. Some parts worked, but a lot of
> things needed attention
> > in _both_ the VM _and_ the Image. In some respect, the "libraries
> interfaced via FFI" had moved
> > faster than the VM.
> >
> > Had Self had a Display Plugin just like Squeak, changes would have been
> much more simple, since the
> > assumptions in the Self world had nod changed at all.
> >
> > So, if things move slowly in VM/Image land and more quickly in library
> land, the answer is Plugins.
> > If things move quickly in VM/Image land and are stable in library land,
> the answer is FFI.
> >
> > I see this in SqueakSSL very prominently. The stable interface from the
> Image land helps a lot.
> > It would be a nightmare to have this via FFI. 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.
> >
> > How does using plugins solve this problem?
> >
> > If a library breaks compatibility, you would have to update the plugin
> and maybe think about how to stay compatible with older Squeaks. If it were
> FFI with a proper facade that finds out how to link to the external
> library, you would need to update the facade and worry there about staying
> compatible, but you could do it in Smalltalk. It requires discipline and
> guidance to only use the facade, of course.
> >
> > Do you mean you can hot-fix a plugin underneath the image, so you can
> run ancient unmodified images on a newer platform/library base? Then maybe
> we do not really want plugins, but proper modules (Smalltalk shared
> libraries/image fragments/image components/parcels/...).
>
> Rather the latter. I wouldn't call it hot-fix but rather evolve stuff as
> they change.
> That's how we do with Display and SqueakSSL.
> You don't need to touch the image, but you could.
> I don't understand how "proper modules" in whatever sense would fix that.
>
> :)
>

Just to follow up on my modules remark: I meant to split the object memory,
or at least the class library, in multiple files, so you can swap one out
for another version if needed, even without needing to run the Smalltalk
system. Like a Smalltalk shared library. Then you could leave the main part
of the image with your work environment untouched, but offline-replace some
subystem like the Display or encryption. Like with plugins.

Since your problem with Self seems to be that you could not modify the
system because you could not run the system in the first place, such
splitting does not help by itself. You would still need a working toolset
to modify another Smalltalk image or parts thereof.

Text editors and C compilers seem to be mostly available on developer
machines, to edit files that don't belong to the text editor or the C
compiler itself. :-)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20200531/21252469/attachment.html>