Hi Adrian,

> If I understand ImageSegments correctly, only objects are stored which are
> not accessible by other objects outside the tree... Doesn't this cause
> problems? E.g each session includes an user in my Seaside app. So, not all
> user objects would be stored, right? (A solution cuold be to avoid
> references by using IDs or the unique username as you describe below).

Shoot, that's right.  You can't hold references to anything inside the
domain outside the domain.  That could get complicated if you have
components holding on to models which are domain objects.  The session holds
onto those components and the registry holds onto the sessions.

You'd have to destroy all sessions before saving to disk.

Or you'd need a marking algorithm to work like the GC algorithm but start
with the parent array as if that was the system dictionary.


>
> Compared to ReferenceStreams, what are the advantages? Speed?
>
> Thanks,
> Adrian
>
> ----- Original Message -----
> From: <goran.hultgren at bluefish.se>
> To: "The general-purpose Squeak developers list"
> <squeak-dev at lists.squeakfoundation.org>
> Sent: Friday, April 18, 2003 4:30 PM
> Subject: Re: Image Segment question -djb
>
>
> > Hi Derek!
> >
> > Derek Brans <brans at nerdonawire.com> wrote:
> > > Hi Goran,
> > >
> > > I used your code almost word for word.  It seems to work like a charm.
> AND
> > > your code keeps versions.  How much easier could persistence be?  What
> > > drawbacks have you encountered?
> >
> > Well, not many. Off the top of my head:
> >
> > 1. You can only "snapshoot" the complete model instead of parts of it
> > (like Magma can using transactions). But this is often ok, for example
> > in simple applications or "documentish" apps. In two of my apps I have
> > been forced to "split" my models in order to be able to save two
> > different parts in ImageSegments of their own. I just cut the normal
> > object reference and turned it into an integer id instead in combination
> > with a Dictionary. Sure, ugly - but if you can get away with just a few
> > different parts then it's still ok. My apps saved personal accounts
> > separated from the documents they contained.
> >
> > 2. ImageSegments are either *completely in RAM* or *not*. This means a
> > single ImageSegment can't get too large. But again - for many apps the
> > amount of available RAM today is more than enough.
> >
> > In short - using ImageSegments like this is a solid way of
> > loading/unloading parts of the object memory. Sure, saving forces more
> > or less a GC so it can take a little bit of time - but it's still very
> > fast.
> >
> > When this mechanism is not enough Magma is probably the logical next
> > step - more or less the same simplicity but with transactions, scalable
> > collections, networking, locks, faulting policies and all those other
> > goodies that you may want when moving forward. And it would be very easy
> > to change an app into using Magma since both techniques are very
> > non-intrusive (compared to RDB solutions which tend to crawl all over
> > the place).
> >
> > But Magma wasn't there when I started using ImageSegments! :-)
> >
> > regards, Göran
> >
>
>
>