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

[Eben Eliason]

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.

> 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. The system isn't designed
to prevent versions of an object from joining into a single shared
session (that's clearly the desirable outcome)...it's designed to
allow them to be joined the old-fashioned way if there's no better
alternative. I'm basically stating that the fallback should always be
to launch the two instances (same activity_id, different version_ids)
side by side. This fallback should only happen if the activity can't
do something smarter. Any activity using GroupThink, for instance,
could do something smarter. But we need to engineer the solution you
propose in such a way to allow the less elegant default to still work.

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. There are some interesting details in this model,
such as the fact that any open activity that has been changed needs to
have a new version_id assigned to it immediately, so that it is
distinct from the version that it was opened as. My assumption there,
by the way, is that the shell won't have to ask if it finds another
activity with the same (activity_id, version_id) pair already open; it
can implicitly just join the open one.

Eben


> --Ben
>
>