Hi Göran, Hi Derek

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).

Compared to ReferenceStreams, what are the advantages? Speed?

Thanks,
Adrian

----- Original Message -----
From: <goran.hultgren@[...].se> 
To: "The general-purpose Squeak developers list"
<squeak-dev@[...].org> 
Sent: Friday, April 18, 2003 4:30 PM
Subject: Re: Image Segment question -djb


>  Hi Derek!
> 
>  Derek Brans <brans@[...].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
>