VMMaker organzation (was: Re: [Vm-dev] Fwd: Include Cryptographic Primitives In VM's - DESPlugin)

[Andreas Raab]

Hi Tim and all -

I'm wondering if we shouldn't "decentralize" the development of VMMaker 
a little. Right now, it seems pretty awkward for someone developing a 
plugin to update that plugin in any reasonable way. For example, the 
current VMMaker release has a somewhat outdated CroquetPlugin which 
-while not horribly broken- fails a few important tests in replication 
(I only noticed that over the weekend btw). The current solution set 
consists of me sending something via email to you in the hope it'll end 
up in some future version of VMMaker. Whether it's gotten there or not I 
can't tell without actually looking at the code itself, e.g., there 
isn't an easy way for me to say "oh, no, Tim's forgotten to include the 
latest Croquet plugin for the 3.9 release! Where is the tar? Where are 
the feathers?" ;-)

So here is a question: What if we organize a monticello repository with 
sub-packages for the individual plugins which then get updated by 
individuals maintaining these? What I'm thinking about is something like:

   VMMaker-Generation (CCodeGen, VMMaker, UI)
   VMMaker-Interpreter (ObjectMemory, Interpreter)
   VMMaker-Crypto (all the crypto plugins)
   VMMaker-Croquet (all the croquet related ones)

etc. This would allow (say) Ron to update the crypto plugin 
independently from me updating the Croquet plugins and it wouldn't 
require you to be in the loop for every minor change. "Real" releases 
might be managed simply by posting a Monticello configuration that lists 
all the packages for that particular version of VMMaker (plus optional 
file releases through SM - I've used load scripts to good effect for 
that in the FFI and one could probably even write a translator that 
takes a configuration as input and spits out an SM loadscript).

Does this make sense to anyone but me?

Cheers,
   - Andreas


tim Rowledge wrote:
> 
> I'll add DESPlugin to the next release of VMMaker and you can then 
> persuade the vm makers to make sure it is included for testing.
> 
> tim
> -- 
> tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
> Great leaders inspire by example. When that's not an option, brute 
> intimidation works pretty well.
> 
> 
>