In message <p0431010eb55177d7f15b@[10.0.1.4]>
          "Andrew C. Greenberg" <werdna at gate.net> wrote:

> >Finally, a little survey: How do you guys think about distributing a 'fat'
> >VM - that is a VM that has all the plugins builtin so that no extra plugin
> >DLLs are needed?! It would reduce the chance of accidentally using an
> >outdated plugin and possibly make redistribution a bit easier. Do you care?!
> >If so, let me know. I'm your (not so) humble servant ;-)
> 
> I've always been of the view that plugins should be placed in a 
> blessed folder, as is done with most other pluggable applications. 
> Perhaps one named "Plugins"?

Since I've been the one pushing for a pluginized VM, I guess you can
assume I prefer a split-up VM. Of course, my platform makes it dead easy
to do, so I'm bound to go that way. However, I really can't see many
problems with the idea on other platforms (at least, the usual desktop
suspects) since it seems pretty simple to have a directory (ok, folder
for you macolytes) with some plugins in it. The most likely work needed
to support it is making sure the directory (folder) is the first place
in the search path for plugins.

> 
> While a single, fat, application would reduce the chance of 
> accidentally using an outdated plugin, it likewise reduces the chance 
> of updating the interpreter by seperately compiling a new replacement 
> plugin, or of permitting a user to delete those plugins they may not 
> desire.
Actually, Andreas did some really neat work to make sure you can
over-ride a built-in plugin with an external one. So you can update a
fatVM, but you 'lose' some memory space.

And...
In message <392BEA71.F68FC9B7 at evolgo.de> stephan wrote:


> This sounds good to me.
> 
> But for the standard distribution I would suggest to
> - distribute all plugins used in the distributed image;
> - check for existence of one of these plugins at - at least - first
> startup, to
> 	- give the user a warning, if the installation is wrong (plugin not
> found),
> 		-> if he deletes plugins later, it's his own risc.
In a way this happens by default, since one of the first things the
normal image does is load the FilePlugin. At the moment if it fails to
load properly (ask me how I found out...)  you get an ugly and annoying
notifier on a partially drawn screen. We could trap this a bit more
politely and provide a nice warning.
>  

> 
> This is true. But for - most - users without the ability to compile
> VM/plugins it is difficult to install new/updated modules (compiled
> plugins).
It's not at all difficult - the plugins would be already compiled and
you just copy them to the right place. We should be able to make that
a trivial addition to the update mechanism.


And....
In message <IBECLDFOJMPKCBMGAPCOEEEGCBAA.spair at advantive.com> Stephan
Pair wrote:

> 
> Are version numbers also checked?...it would be nice if the VM didn't use a
> plugin if it has a built version that is newer.
I've just finished this.
I thought it would be a couple of hours work; well, you would, wouldn't
you? The framework is all there working already, just add a prim to run
down the list of installed modules (Andreas had already provided a
simple one for built-in modules) and then a method to use both prims and
add all the results to a list.

Bah! First I had to extend the module naming rules and mechanism to
allow a bit of version info to be added. The default for now is just the
date when the code is generated plus an (i) or (e) depending on whether
the code is made for a builtin or external plugin. It would probably be
nice to make a clean way to include the VM_PROXY_MAJOR & MINOR numbers,
and perhaps the latest update loaded in the generating image?

Once that all worked (involving some head scratching for a few hours
during which I couldn't persuade my system to build anything, let alone
a VM), I  moved across to test on Linux and (re)discovered the delights
of code drift. Most of the stored .h file strings in the image are not
at all suited to the linux build process - even Johns latest update 2173
missed a couple of crucial things. Eventually I seem to have got it all
together.

I want to do one more run of clean-build tests to make sure and then
I'll release it.


tim

-- 
Tim Rowledge, tim at sumeru.stanford.edu, http://sumeru.stanford.edu/tim
Strange OpCodes: SVE: Skip on Vernal Equinox