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

[Eben Eliason]

On Wed, Jul 1, 2009 at 4:57 AM, Tomeu Vizoso<tomeu at sugarlabs.org> wrote:
> 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?

I think we're close. The high level requirement is an API by which an
activity can attempt to perform a merge operation before the shell
simply opens two activity instances with the same activity_id "side by
side." This has implications for activities, for the shell launching
code, and also for the proper treatment of versions, so there are
definitely details that need to be discussed before code is written.

I think this may be deserving of an IRC discussion.

Eben


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