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

Bert Freudenberg bert at freudenbergs.de
Mon Oct 16 22:54:45 UTC 2006

Am 17.10.2006 um 00:39 schrieb 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?

I got it! I like it! :)

One nit - why don't call it VM-* ? "Maker" is so ... (looking for one  
of Tim's terrifically magniloquent terms)

- Bert -

More information about the Vm-dev mailing list