[sugar] Question about clipboard service

Eben Eliason eben.eliason at gmail.com
Wed Aug 6 16:32:35 EDT 2008


On Wed, Aug 6, 2008 at 4:22 PM, Bastien <bastienguerry at googlemail.com> wrote:
> "Eben Eliason" <eben.eliason at gmail.com> writes:
>
>>> 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
>
> About step 11: how B is to know what part of his own version he has to
> copy to the clipboard?  Is this by comparing A's version with it's own?

Yes.

> When the activities will re-open in the same shared-state they were when
> closed, it might be very useful have a function to let A and B check for
> diffs and merge their two versions - without doing manually.

Agreed.  This gets tricky fast, and it's something that can only be
handled well at a per-activity level.  We might be able to offer some
trivial merge APIs, but beyond text, it's not so simple.  This API
would need to be able to detect when two versions of the same activity
(same activity_id, different version_id) are opened/shared, and
attempt to enter some special "merge mode" to resolve any issues.

In any case, the intent here is to illustrate that a completely "dumb"
manual merge makes this asynchronous collaboration possible until we
have better technical solutions.  It's really the same type of use
case as having each person start their own MS Word doc, emailing them
all to a group leader, and then having him manage the merge.  We just
bypass the need for the email with the synchronous collaboration, and
also allow the merge to be accomplished collaboratively, so it's not
on the shoulders of one individual.

It still sounds like a decent step forward to me, even without
automatic merge assistance.

> There might be an "easy-merge" mode where conflicting changes are just
> ignored, and an advanced mode where A and B can resolve the conflicts.

There has been discussion in this area.  We should probably come back
to it once we actually have the rest of the collaboration details
taken care of.  We don't want to complicate things until that works
predictably.

- Eben



More information about the Devel mailing list