[Sugar-devel] GSoC Groupthink Update: SharedTextDemo-4

[Eben Eliason]

On Fri, Jul 17, 2009 at 1:23 PM, Walter Bender<walter.bender at gmail.com> wrote:
> On Fri, Jul 17, 2009 at 12:35 PM, Benjamin M.
> Schwartz<bmschwar at fas.harvard.edu> wrote:
>> Walter Bender wrote:
>>> On Thu, Jul 16, 2009 at 10:06 PM, Benjamin M.
>>> Schwartz<bmschwar at fas.harvard.edu> wrote:
>>>> 1. Any session saved in the Journal that was previously shared, will be shared
>>>> again with the same scope upon resume.
>>>> 2. If there is an existing shared session visible with the same activity_id, the
>>>> activity will join that session.

I think this is good, but again want to state that I personally feel
that this should happen only when the session being resumed is the
most recent in the individuals thread. It should be possible to open
older versions of the session without instigating a merge.

>>>> This behavior is good enough for me.  However, it does preclude users from
>>>> working privately on the results of a shared session, unless they totally

Perhaps this could be accommodated by allowing different types of
"resume" actions. For instance, we've long desired to have both
"start" and "start with >", where the latter would reveal a submenu
allowing a child to start an activity in a "neighborhood" scope, or
with individual friends (and later groups). Perhaps we could likewise
have "resume" and "resume alone", or something similar, so that the
choice can be made in the process of resuming the session.

>>>> deactivate their network connection.  I could add this ability to work
>>>> privately to groupthink's GroupActivity superclass, or it could be added to
>>>> sugar's Activity class.  A number of other interesting behaviors, such as
>>>> forking an existing document, are also unavailable in the present system.
>>>
>>> Maybe an option for "keep" could be to "keep a private copy"?

This has always been my mental model for the "keep a copy" button (not
the "keep" button). I think my thinking is similar to Ben's, here.

>> I think this makes sense.  "Keep a copy" would reset the sharing scope to
>> private, and create a new activity_id.  It's hard to reason about, but I
>> think this makes sense for a versioned datastore as well, where creating a
>> copy is only necessary if you want to break the history (otherwise Keep is
>> sufficient to make a checkpoint in the version history).

Yup.

>> However, this still doesn't allow temporary private work.  In order to be
>> able to work privately on a shared document, and then later merge it back
>> into the shared stream, users would need to be able to choose to work
>> privately for a single session, without altering the activity_id.  It's
>> not yet clear to me how important this feature is.
>>
>> --Ben
>>
>>
>
> A private copy can be shared again. So it seems the real question is

That's true, but if the new copy is private, it will have a new
tree_id and be part of a new thread, with a separate history. It would
be possible to manually merge this with the former thread, or share it
with others in its current thread, but the two threads would not be
automatically merged.

> one of merging. If each of us are working on different versions and we
> want to share again, we need some reconciliation mechanism. I would
> argue that for the time being, that should be a manual process.

I think manual merge should always be the fallback. However, I like
the idea of supporting automatic merge of the "most recent" versions
from several individuals in a collaboration thread.

Eben

> -walter
>
> --
> Walter Bender
> Sugar Labs
> http://www.sugarlabs.org
> _______________________________________________
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>