I can only speak for the one I know.

> - keep the footprint of the image small

The Magma Server footprint is very small because nothing is cached.  Also, no
domain classes need to exist the server, it only deals with enough buffers for
the current read or commit and the integer oid relationships in them.

> - separate image and (data-)objects

I presume you mean persistence here..?

>   -> I even want to put image and DBS on different computers

Yes, recommended.

> - keep the objects, even after a crash

Magma is still a risky database, it has no logging and no crash recovery.  It's
on my list for 1.0final.  That's not to say it wouldn't survive a crash, but if
it were in mid-write when power is lost, there could be trouble, especially if
writing to MagmaCollections files at that moment.

>   -> backups

No logging, no on-line backup.

> - allow access by multiple users over a secure path
>   -> transactions, authentication and authorization, SSL or equal

No security.  I have begun preliminary analysis for a capability model..  but
my RemoteProxy work for peer-to-peer sharing needs to be done before that can
reailistically get started.

> - don't pay money for a DBS
>   -> this should be a free project

Darn..  I don't need much..  :p