[sugar] Importing objects from journal

[Eben Eliason]

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

- Eben