[sugar] Importing objects from journal

[Tomeu Vizoso]

On Wed, 2007-09-26 at 00:30 +0200, Bert Freudenberg wrote:
> On Sep 25, 2007, at 21:32 , Eben Eliason wrote:
> 
> >>> We have chosen to not support links to other objects in the journal.
> >>
> >> That's what I feared.
> >>
> >>> This will waste space, but simplifies greatly things and we hope  
> >>> will
> >>> give a better experience.
> >>
> >> How would the inability to automatically track changes of an imported
> >> object "give a better experience"?
> >>
> >> It does simplify things, even more so, it over-simplifies them.
> >
> > The main problem we wish to address is, of course broken references.
> > I worked for 5 years in our computer cluster at Carnegie Mellon, and I
> > can tell you that even for relatively intelligent college kids, the
> > notion of alias/references within projects can be either hard for many
> > to grasp, or easy for them to forget about when it matters.  Countless
> > video editing, director, flash, and other projects were lost in their
> > entirety because of this phenomenon.
> >
> > Obviously it has many benefits for advanced workflow scenarios, but it
> > has some overhead.
> >
> > As such, we made the choice to embrace self-containment, both as a
> > means by which to prevent accidental loss of data (at the cost,
> > perhaps, of increasing data consumption), and to simplify
> > collaboration and sharing models, so that when I pass you my essay,
> > you naturally receive any embedded images without going through some
> > network kung fu.  It's even more complicated with synchronous
> > collaboration, since I might be editing a document at home that
> > references a file on your laptop, for instance.  If, on the other
> > hand, we implicitly transfer the referenced files so that all of our
> > references are at least local, what happens when our local versions
> > get out of sync?  All of a sudden, we're recursively managing embedded
> > files, when it's challenge enough to keep the top level document in
> > sync.
> >
> > It also greatly simplifies the interactions with the datastore, and,
> > perhaps, actually serves as a better indication of true memory usage.
> > If I embed a photo in Write as a reference, and later want to delete
> > it, one of several things can happen:
> >
> > 1) we can keep an accurate reference count (or some similar technical
> > solution) and refuse to allow the deletion (or, at least, warn them
> > beforehand of the reference)
> >
> > This isn't ideal because it may not be evident to the kid why they
> > can't get rid of it (or why they shouldn't).  It's unclear if it would
> > be understood.
> >
> > 2) we can simply delete it, breaking the reference
> >
> > This is "simple", but doesn't really solve the problem at all.
> >
> > 3) we can implement some form of intelligent and incredibly
> > complicated "copy-on-delete" approach
> >
> > This would make the interaction simple, because I could simply delete
> > this old photo without fear of breaking other projects.  However, it's
> > more confusing from a memory management perspective, since either a)
> > the file is not really deleted, but rather hidden from the user and
> > marked for automatic deletion when no references require it anymore or
> > b) it gets copied into every activity which refers to it.
> >
> > In the case of (a) no space is recovered, since the file remains, even
> > though the kid may have deleted it to save space. With (b) we actually
> > increase storage costs (not to mention, I don't think it's practical
> > anyway since only the activity itself could know how to properly embed
> > the object within its own entry)
> >
> >>> This was decided expecting that differential storage and transparent
> >>> backup to the server will reduce the impact of storage waste and  
> >>> that
> >>> self contained objects will allow for easier sharing and  
> >>> management of
> >>> journal objects.
> >>
> >> Well, this wouldn't necessarily preclude optionally tracking objects,
> >> an activity would have to be prepared that the object may not be
> >> available, and in this case just continue to use its own copy.
> >
> > This is true.  It's really a powerful use case, and it might be
> > something to consider in the future.  Perhaps there is a way to
> > support it for those that explicitly choose to use references (in a
> > video editing activity, there may be no way around it, anyway...)
> > Perhaps our model is wrong altogether and references are fine, but we
> > need to do a lot of discussion about the implications and figure out
> > how to handle the complications that will arise.
> >
> > I'm certainly open to discussion in this area, because it's a really
> > interesting space.  It is not, however, a space within which we can
> > move quickly or without careful consideration.
> 
> You're raising good points. For now erring on the side of simplicity  
> does seem advisable. I'll have to think more deeply about how we can  
> deal with this for Etoys.

Keep in mind that by now nothing stops your activity from storing
references to journal entries using the entry uid. What you don't get is
extra support from the datastore for this.

Perhaps Michael have something to say about the security implications of
this.

Tomeu