[Telepathy] [Sugar-devel] Sugar Presence Service and Resume Behavior

[Tomeu Vizoso]

On Tue, Jun 30, 2009 at 06:01, Eben Eliason<eben at laptop.org> wrote:
> On Mon, Jun 29, 2009 at 11:03 PM, Benjamin M.
> Schwartz<bmschwar at fas.harvard.edu> wrote:
>> Eben Eliason wrote:
>>> On Mon, Jun 29, 2009 at 10:34 PM, Benjamin M.
>>> Schwartz<bmschwar at fas.harvard.edu> wrote:
>>>> Eben Eliason wrote:
>>>>> I know GroupThink does everything it can to prevent collisions, but
>>>>> with this we should also be thinking about the worst case. The
>>>>> intended baseline behavior (before we get into any fancy merging
>>>>> libraries) was to allow two instances with the same activity_id but
>>>>> different version_ids to run simultaneously, and be joined by any of
>>>>> their participants, thus allowing manual copy/paste merging. The
>>>>> instance left open last would then become, naturally, the most recent
>>>>> and therefore the "agreed upon" version moving forward.
>>>> Hmm.  This creates a bit of a dilemma.
>>>>
>>>> In Groupthink, there is no such thing as a collision.  You could say
>>>> "collisions are not supported".  Therefore, my model has been that
>>>> different versions of a document should always be launched into a single
>>>> shared session, where the data will be merged immediately and
>>>> automatically.  If the user wishes to create a separate branch not to be
>>>> automatically merged with the existing document, she should create a copy
>>>> of the journal entry with a new activity_id. (No, we don't seem to have a
>>>> UI for that.)
>>>
>>> The most basic UI for that, as I see it, is a "Keep a copy" secondary
>>> item under the Keep button.
>>
>> Yep.  This is what I expected the "Copy" option in the Journal to do, but
>> that copies to the clipboard.  Two options, "Copy to Clipboard" and "Copy
>> this Entry" would be necessary
>>
>>>
>>>> If the system is designed to prevent different versions from joining into
>>>> a single shared session, then perhaps this explains the observed behavior.
>>>>  It also entirely prevents automerging of offline work.
>>>
>>> I don't think they're incompatible at all.
>>
>> I think we agree that they are incompatible as currently implemented, and
>> that any implementation that permits this sort of automerging looks
>> substantially different from what we have now, as you detail.
>
> Yup.
>
>>> Hence, perhaps some need for asking an open activity instance if it
>>> can successfully "merge" (whatever that means to the activity) some
>>> other object handle its given. If success is returned, the merge
>>> happens; if failure is returned, the shell opens the requested
>>> activity normally.
>>
>> I do not think an "object-based" merge system is best for this purpose.
>> It seems to me that such a system would prevent any online "negotiation"
>> between the two sides.  Things get dramatically uglier if you consider
>> joining a session containing many members, but not the initiator.  Which
>> user gets to decide whether the new one can join, when all users are equal?
>
> The leaderless merge issue doesn't seem any harder than the basic
> leaderless collaboration issue. But I might be missing some obvious
> complications. The short of it seems to be that the activity would
> have to elect a given client to handle the merge.
>
>> It's not exactly a beautiful solution, but I'd prefer a toggle in
>> activity.info: automerge=True/False.  If automerge is False or
>> unspecified, then we retain the current behavior (for the sake of
>
> And because the current behavior is the "correct" thing to do if merge
> can't be automatic anyway!
>
>> compatibility).  If automerge is True, then different versions are always
>> combined into a single shared session.
>
> I'd carefully word this as "always attempted to be combined"...
>
>> To support "unreliable merge", we can use a self.unshare() method.  If the
>> local activity process, after negotiating with other group members,
>> decides that merge is impossible, then it may leave the shared session
>> shortly after joining and return to private scope.
>>
>> How does that sound?
>
> This sounds almost exactly like what I was suggesting, but in the
> opposite direction. I was proposing to ask the activity on the fly if
> it could perform a merge (this method would return false if
> unimplemented), returning false when it wasn't possible (after
> whatever negotiation was necessary...this method could be async).
> You're suggesting to first check a global constant defined by the
> activity to see if it will even try to merge at all, and a second
> fallback method to be called (by the activity) in the case of a
> failure. Actually, I guess if it's async, our two methods are
> basically the same, except that you suggest the addition of the flag
> in .info, which seems like a reasonable enough idea, though not
> strictly necessary.
>
> In any case, both seem roughly equivalent in terms of experience, in
> which case I don't really care. =)

Ben and Eben, do we have now a clear idea of where the problem lies
and which API needs to be added to solve it?

Thanks,

Tomeu

> Eben
>
>
>> --Ben
>>
>>
> _______________________________________________
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>