new package structure

[Chris Muller]

> Yeah, the Configurations thing is a neat proof-of-concept but needs a
> lot of work to be actually usable...

Hopefully either that or some other solution will spring forth.  Kabunga seems
to be SqueakMap oriented.  I checked out Universes but didn't really have time
to understand them..

> Why did you chose to live on without dependencies, anyway?

Well, I think you know why.  ;)

But I'm thinking that I may actually enjoy it in the long run; there will be a
lot less duplicately saved packages; i.e., every version of the code packages
will have meaningful changes.

Further, the ability to load and save independently would seem to better
faciliate collaborative development; i.e., you can load and save the individual
packagse but leave the "Loader" packages pointing to the current "Release".

> Talk about packages: there seem to be an awful lot of them in current
> Magma. And personally, I find they really clutter up the browser. Now,
> there are two solutions to this: build a browser that can better
> handle lots of packages, or whine about packages split up in lots of
> subpackages ;).

Yea, I agree it is a lot of packages.  Thankfully they all start with "Ma" so
at least the clutter is altogether instead of interspersed.

I doubt whining alone will go very far with me; you should suggest a good
alternative.  :)

The main thing is, I see packages (and, ultimately, configurations) as much a
unit of software-construction as classes and methods; just a bit
larger-grained.  The package divisions in Magma were chosen to isolate the
various responsibilities, and to avoid duplication in other frameworks that
need the services of the various subpackages.  "Ma object serialization", for
example, is independently needed by "Magma client", "Ma client server", "Ma
Armored Code" and "KryptOn".  I certainly wouldn't want to duplicate all that
code in each of those packages individually.  

However I am very open for ideas to improve the situation..