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

[Benjamin M. Schwartz]

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.


> 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?

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
compatibility).  If automerge is True, then different versions are always
combined into a single shared session.

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?

--Ben

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: OpenPGP digital signature
Url : http://lists.freedesktop.org/archives/telepathy/attachments/20090629/bb0b4559/attachment.pgp