[Vm-dev] Auto-load plugins from the net (was: VM Maker: VMMaker.oscog-eem.2347.mcz)

[David T. Lewis]

On Thu, Mar 08, 2018 at 09:56:29AM -0800, tim Rowledge wrote:
> 
> > On 08-03-2018, at 7:57 AM, Eliot Miranda <eliot.miranda at gmail.com> wrote:
> > 
> > but since we no longer include the processor simulator plugins in the standard vm builds, the VM obtained by
> >     image/getGoodSpur[64]VM.sh
> > won't allow simulating the CoInterpreter (the JIT), only the StackInterpreter.  So this needs to be fixed.
> > 
> > I could build the processor simulator plugins and put them on my website or we could set up a build on the CI infrastructure. 
> 
> I'd urge having them built by the autobuild stuff for consistency. It must
> surely be possible to have the built external plugins moved off to one
> side as part of that build? Then we'd 'merely' need a suitable link in
> the download page(s) to point to them for manual fetching and a stable
> address so that Eliot's build-vmmaker script can reliably find them.
> 
> In fact, having reliable URLs for any of the external plugins (strictly
> speaking any plugin, since we can over-ride an internal plugin if needed)
> would be interesting because then we could actually do what was originally
> intended with the "I can't find no stinkin plugin of that name!" error,
> which was to handle it by looking up on the net for a plausible version
> and installing it and restarting the operation. Maybe a mere 20 years later
> we can actually implement this?
>

That's an interesting idea, first I've heard of it. Can you sketch out how
such a loading scheme might work?

I am envisioning something along the lines of:

- try loading the primitive
- if not found determine name of the plugin for that primitive
- look up href location for the plugin (modulo 32/64 bit host/image)
- also check if we tried this once before, don't try it again
- download plugin file to a writeable location on your computer, where that
  location would be in the lookup path for module loading
- maybe validate the file in some way for security
- try loading the primitive again
- if not successful, remember that this primitive is not available, then fall
  back on the actual fallback code

Is that the idea?

Dave