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

[Eben Eliason]

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. =)

Eben


> --Ben
>
>