[sugar] Question about clipboard service

[Eben Eliason]

On Wed, Aug 6, 2008 at 12:12 PM, Greg Smith <gregsmitholpc at gmail.com> wrote:
> Hi Eben,
>
> Thanks for the explanation. You may want to update the Spec with this
> added detail.
>
> One follow question. On this:
> ********
> If 5 kids are collaborating on a science report, they might all go
> home and do independent work on their subtopic as homework.  The next
> day they come together in a single shared Write session and use the
> clipboard to aggregate their individual efforts into a final report.
> *********
>
> Can you walk me through the steps needed for that? e.g. one kid starts an
> activity then shares it, each other kid opens the activity and joins (or
> opens their own work?), then ???. How do they get their own work on the
> clipboard and how do they add it to the shared activity?

Step by step. I limit the example to 2 kids for simplicity; the method
scales naturally.

1. Kid A starts an activity
2. Kid A shares the activity
3. Kid B joins the activity
4. Kids A and B collaborate (synchronously) in the activity
5. Kids A and B go home
6. Either kid A, kid B, or both work in the activity (asynchronously)
7. Kids A and B come back to school
8. Kid A opens his version of the activity*
9. Kid B joins A's version of the activity
10. Kid B opens his own version of the activity**
11. Kid B copies part of his own version to the clipboard
12. Kid B pastes that clipping into A's version of the activity
13. Kid B closes his own version of the activity
14. Kids A and B continue working (synchonously) in the merged
activity (formerly A's version)***

* Here we assume that the activity is implicitly shared when resumed,
having the same participants it had previously.  This is not currently
implemented, and should be discussed further.  At present, the
explicit sharing step would be required here as well.

** This step requires that it be possible for multiple versions of the
same activity (having same activity id) to be opened at once.  Based
on the note on step (8), this isn't presently a problem at all, since
collaboration scopes aren't retained, and each Journal entry is
treated as an independent entity.  We need to be careful to support
this properly as we move to a true versioning Journal with proper
collaboration support, such that the (activity_id, version_id) tuple
is the identifier for a given instance.

*** Note that either of kids A and B could join the other's open and
shared version of the activity.  In the "new Journal" this would
result in those other "intermediate" (actually, branched) versions to
appear as entries within their Journal history.  The important point,
though, is that the most recent version saved will continue the
collaboration forward, which means that as long as the "chosen" good
version (the one with the proper merges) is closed last, it will
appear as the latest version for both (or all) of the kids.

- Eben


> Thanks,
>
> Greg S
>