Hi Chris,

I'm studying the design of Magma hoping to glean some ideas for my own
OODB implementation.  The approach that you and I have taken are very
similar in some respects, and very different in others.  I have a few
questions...

I notice that you are assigning oids to every object that is stored in
Magma and using a WeakKeyIdentityDictionary for storing the oids.  One
issue I had with that approach is that I think it runs into scalability
issues when you approach and surpass 4096 objects (due to the number of
bits available for the identity hash).  Is there a way to make this
scheme more scalable?  Or, is it possible that it will be rare to have
more than 4000 persistent objects cached on the client?

How are you tracking the changed objects?  It looks like there is some
mechanism that you are using to track changed objects, but in the brief
look I had, I couldn't see what you were doing.  Are you just saving all
client cached objects when a transaction commits?    

It takes a long time to establish a MagmaSession (especially after some
objects have been populated in the server)...can you describe what's
happening when connecting?

I see that you are using a stubbing mechanism (ala GemStone) that uses a
ProtoObject and #doesNotUnderstand: to transparently forward messages to
the real object.  Are you also using #become: to change these objects
into their real counterpart?  If so, won't this present a performance
issue under certain circumstances (where one or both of the objects are
in old space)?  Also, did you implement a "stubbing level" mechanism ala
GemStone?

Is there any kind of cache control in Magma?  For example, if I have a
client that is running for many weeks and accessing lot's of objects,
once they are pulled from the server to the client, are they going to
stay in the client indefinitely?  Is there some way of controlling how
many objects are retained in the client's object memory?

Magma looks great...thanks and keep up the good work.

- Stephen