[sugar] Importing objects from journal

[Samuel Klein]

On 9/25/07, Eben Eliason <eben.eliason at gmail.com> wrote:

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

I was thinking of a different sort of 'link'... not an embedding at
all.  A link that doesn't guarantee anything on the other end, but
says 'this linked to something real elsewhere when it was created' has
value if the links themselves are meaningful parts of the system.    I
am thinking of something like a 'catalog' activity that includes a
link to thousands of other things on the system, where you explicitly
don't want to keep a local copy; for those purposes, it would be
useful to be able to explicitly ask for a link instead [if the
original goes away, you now no longer want the link to work].

On 9/25/07, Eben Eliason <eben.eliason at gmail.com> wrote:

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

I was thinking of a different sort of 'link'... not an embedding at
all.  A link that doesn't guarantee anything on the other end, but
says 'this linked to something real elsewhere when it was created' has
value if the links themselves are meaningful parts of the system.    I
am thinking of something like a 'catalog' activity that includes a
link to thousands of other things on the system, where you explicitly
don't want to keep a local copy; for those purposes, it would be
useful to be able to explicitly ask for a link instead [if the
original goes away, you now no longer want the link to work].

SJ



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

<nod>

SJ