Magma update

[Chris Muller]

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)