On Wed, Aug 6, 2008 at 12:12 PM, Greg Smith <[EMAIL PROTECTED]> 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 > _______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel