Next steps

[Chris Muller]

Hi Göran, what a dream project you have started!  The
very best projects are the few forging new territory
and leading by example by progressive thinkers like
yourself and progressive technologies, way to go.

(I like to respond to your earlier note as well, sorry
for the delay).

> 3. The new system is intended to support offline
> operation, meaning that
> users will be able to make a standalone installation
> on their laptops
> and then replicate a portion of the model to it,
> work offline, and then
> sync up later. I will be using a "prevaylerish"
> pattern to accomplish
> that, or call it a Command pattern if you like. I
> also note the
> existence of Magma's forwarding proxies (might get
> handy). So yes, the
> laptops will in that case run a local Magma with a
> subset of the full
> db.

This function will be built into Magma.  "1.1" has
security, "1.2" will have security and "import/export"
of large chunks of the persistent model.  1.2 is the
very next thing I intend to work on as sooon as the
1.1 and KryptOn are stabilized.

I would like to share a few more thoughts about this
function.  The idea is that Magma is too centralized. 
There needs to be a way to accmoplish exactly what you
said, for someone to be able to "download" a chunk of
the model for their own offline work (i.e., on a
plane) and then, later, 'sync-up'.

I also intend for this to serve as the basis for "long
transactions."

Now, I want to try to avoid the notion of a "master"
and "replicate".  Instead, any repository can simply
be a conglomeration of objects from many other
repositories, and the repository knows from whence
each object "originated" to support the sync-up.

If there is a commit-conflict during the sync-up, the
committer can only get through that by bringing down
the objects in conflict into their own repository,
reapplying their updates, and then try to commit
again.

Bottom line, you can download your own copy of of the
model and that copy is "yours" (you could host it, for
example).  But the one you copied from is not yours,
therefore the burden of commit-conflict reconciliation
is always on the committer.

This function, combined with the ForwardingProxy's I
hope will be sufficient for collaboration on
large-scale domain models in a distributed fashion.

> 1. Regarding wrapping each request in a commit - how
> costly is that? The
> abort/begin is of course needed (and how much does
> an abort cost if no
> modifications have been made?), but how much does
> the commit cost if I
> say do no modifications but have a large "read set"?
> I am guessing this
> is much cheaper if I use WriteBarrier? Is the
> WriteBarrier code fine to
> use?

A commit is pretty cheap with a small readSet.  With a
large readSet, WriteBarrier will definitely improve it
dramatically.

WriteBarrier is still supported, but I haven't tested
it in a while.  WriteBarrier itself also has at least
one bug related to changing the class-model while
objects are behind a WriteBarrier.  Therefore, you
should never use WriteBarrier in a development
environment where classes will be recompiled.

Still, it is probably good to try to keep the readSet
as small as possible.

> I noticed: 
> 	http://minnow.cc.gatech.edu/squeak/5832
> 
> ....and accidentally that is exactly what I need. :)
> Now, it doesn't
> necessarily fit me - so I am using a prevaylerish
> approach with
> "command" objects that I also save to Magma so that
> I can reconstruct
> the model by applying the commands in sequence. This
> should give me a
> suitable mechanism to keep Magma database copies
> (offline clients) in
> synch with the master and also reasonable hooks to
> figure out "logical"
> conflicts.

As mentioned, I would like this to eventually be
supported at the database level.

> Also, the security stuff in 1.1 is interesting - we
> might want to use
> repository file encryption (or just rely on OS level
> mechanisms for that
> - encrypted filesystems).

Sure, all of the security can be essentially disabled.
 The choice is yours.

> Was there any other relevant changes with 1.1?

Not in terms of major functionality, but there was
some simplifying of the ForwardingProxy's
implementation.  Some other minor refinements too.. 
1.1 is definitely the intended "future" of Magma
unless there is some huge backlash to the security..

Regards,
  Chris