[sugar] Ownership of activities OR duplication of objects OR understanding journal entries

[Eben Eliason]

Hello all -

The following is a snippet from a discussion about the Journal, and
particularly about the copying of files to external devices (and by
extension to anything that is not the Journal: clipboard, bboards, sending
to friends, etc). I'm forwarding this all of you so that we're all in
agreement on this point, since it's a pretty fundamental aspect of the
behavior of objects on the laptops.

> > My understanding is that once an entry is copied to an pen drive or SD
> > > > card, it's not versioned any more (behaves like in Trial2). Once an
> > > > entry is copied from the external device to internal flash, it
> > becomes
> > > > version 1 of a new entry. Eben, is this correct?
> > >
> > > I'm not sure that's necessarily true, but I'll have to think about it.
> >
> > >  This touches on a bigger question, which is how can I show my drawing
> > > to you or the class without allowing you to draw all over it (without
> > > inviting you to join it).  Maybe this is in fact the answer:  any form
> >
> > > of copy -- be it to a USB drive, to the clipboard, to a bboard, or to
> > > a friend (via "send to friend" when it exists) creates a new
> > > activity_id and assigns a private scope.  It basically makes it a self
> >
> > > contained and private object which they can look at, modify, share
> > > with others, etc. without in any way affecting my own history and
> > > versions.  That actually makes a lot of sense, and solves some
> > > problems.
> >
> > Yup.
> >
> > > The only case where this doesn't quite work is with my own USB drive.
> > > If I want to personally backup something that I'll later use again, it
> > > would be nice if it retained it's history within my own Journal.  We
> > > talked about wanting to add hidden identity files to storage devices;
> > > is there a chance that we can maintain the activity_id and version_id
> > > when the identities of the devices (be it journal to USB or USB to SD,
> >
> > > etc) remains the same, but create new ids otherwise?
> >
> > Well, in my opinion we already have the server for backups. I would
> > prefer to stick to the simple solutions by now and reavaluate after
> > Gen1.
>
>
>
> Yeah, I think that's reasonable.  Treating them as independent objects
> once they leave the Journal is a simpler model for sure, and solves many
> more problems than it creates.
>


To summarize, we're basically making a sharp distinction between
sharing/inviting an activity with someone and giving/copying/posting/sending
an activity to someone.  In the former case, ownership is granted to the
invitee and collaboration happens around the object, which maintains its
version history. In the latter case, the object is transformed into a
self-contained artifact, losing it's history (though not its creator) and
becoming separate from the (perhaps ongoing) collaboration around its
creation.


This makes it very clear that there are separate use cases for "sharing with
the class" and "posting to the class bboard," which is actually a really
good thing.

- Eben
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.laptop.org/pipermail/sugar/attachments/20070820/2d7a2bdb/attachment.htm