Hi all!

Avi Bryant <avi at beta4.com> wrote:
> On Jul 21, 2004, at 12:58 AM, goran.krampe at bluefish.se wrote:
> 
> > Hi people!
> >
> > Just wanted to mention that I will try a different much more pragmatic
> > and simpler solution to SqueakMap in this area. :)
> 
> Aren't you going to tell us what it is? :)

Well, I am going to. :) I just would like to write a clear article on
it.

In short it goes like this:

SM is very "tree" like. And a user can typically only modify the objects
his account owns, this is an important simplification. Co-maintainers
make it slightly more tricky, and the attachable resource will too - but
I will have to write some code to cope with that.

So basically, if I modify my own local (in my image) SMAccount instance
by modifying the SMObjects owned by it and modifying itself etc. Then
noone else should be able to have a conflict with me, disregarding
co-maintainership for a second. And disregarding categories.

This means that essentially I can make any modifications I want, and
then serialize my SMAccount (including everything it owns) and send it
up to the server to replace the old one. And in the same way, when I
load updates I could load only those other SMAccounts that have changed
and replace them in my local SMSqueakMap.

Now... can this be refined? Yes. If I make sure the updated timestamp is
properly maintained (cough) then I can use that as a "dirty mark". To
discover which SMObjects I have modified since last - I can load an old
snapshot of my SMAccount and quickly compare the updated stamps. Then I
can transfer only those that are dirty. And same goes in the other
direction.

So... yes, I am rolling my own poor mans OODB here - using manual dirty
marking and ImageSegment or ReferenceStream to serialize SMObjects. And
then add some logic to handle the parts that *can* cause conflicts
(categories, co-maintained objects) and well, I should be home free.

This will also fit with my new
"servers-structured-in-a-tree"-architecture etc etc.

Anyway, I will sit down and write a detailed description of how it will
work before doing this. But I feel this is such an important step in the
evolution of SM that I might want to do it now. The dependency plan will
probably work less efficiently if we still have to rely on a web UI etc.
I want that ability to modify locally and commit! :)

> Avi

regards, Göran