I just thought I'd describe where Magma is these days.
Besides significant improvement in stability, the last year has seen several features added:
== near-Universal object support ==
Almost any kind of object is supported. The only ones I still need to fix are subclasses of Set and Dictionary (such as PluggableSet and PluggableDictionary). However, Blocks and variableWord and even Morphs and Projects seem to work.
== Collaborative development ==
You can run your image "out-of-sync" with respect to class definitions in repository's you're connected to. Instance variables, like standard Smalltalk, are mapped by name. Magma will even warn you if you are about to truncate an instance variable on account of your in-image definition not having a particular instance variable.
You can also use Magma as a code-repository. Classes, ChangeSets and Monticello packages can be saved to a special area that does not require a connection in order to download and install the code. This way repositories can/should be built to contain all the objects AND code needed to access those objects (self contained repository).
The Monticello GUI can be used to directly load/save packages.
== Remote proxies ==
Magma is intended to run client/server AND peer-to-peer simultaneously. You can have your own personal database in which you may wish to loosely reference an object in another repository. Just send #maAsForwardingProxy to the remote object and commit the result to your repository. Then, any messages you send to that will cause automatic connection to the remote repository and send the message.
== Large-collection enhancements ==
A lot of work has gone into large-collections. Thanks to Brent Pinkney, we now has MagmaSet and MagmaDictionary. These are two classes that act like their Smalltalk brothers, except can hold millions of objects and endure high-concurrency. We also have MagmaArray, which provides fast-access to a very-large Array structure.
All large-collections now work before they are persistent, as well as seamlessly integrating uncommitted objects added during a transaction. Despite these major improvements, add-speed of MagmaCollections has been improved about 400% in the last year. Read-speed was always fast and remains fast.
== Disaster/recovery support ==
It is now (believed to be) impossible* for the repository to become corrupted should a power-outage occur, however the last few seconds (dictated by #cacheFlushFrequency) of commits could be lost unless you set flushAggressively: true, which will affect performance.
== leaner and faster ==
Between WriteBarrier support, a smaller buffer format, large-collection improvements, Magma has maintained a peak commit rate of 24 per second on my machine. MagmaBenchmarker was developed as a basis for assessing performance limitations.
Magma certainly does not have light code-base, but it is better-factored than its ever been. At least two users who have delved into the code have been able to understand it well.
==
* (no warranty see http://minnow.cc.gatech.edu/squeak/5725, evaluate the design and decide for yourself at http://minnow.cc.gatech.edu/squeak/5724)