[Sugar-devel] Sugar Presence Service and Resume Behavior

[Eben Eliason]

On Mon, Jun 29, 2009 at 10:12 PM, Benjamin M.
Schwartz<bmschwar at fas.harvard.edu> wrote:
> My GSoC project involves getting "offline collaboration" working. My model
> for this is that two users can join a shared session, then go offline,
> resume the session from the journal, continue working, and then later
> resume again when they are on the same network/server and have the two
> instances merge.  In Groupthink, all of my algorithms are designed to
> support this.  However, I have discovered that when two such instances are
> resumed, they do not connect to each other.*
>
> I believe the problem lies in the interaction between the Presence Service
> and the Datastore, and before I spend too many hours puzzling out how it
> works, I wonder if anyone could tell me what changes are likely to be
> necessary to achieve the desired behavior.  From my limited understanding
> of the code, it seems that if an instance is resumed from the Journal, its
> unique activity_id might change, and this might prevent it from being
> correctly identified as an instance of an existing shared session.

That sounds pretty broken, insofar as the activity_id, from the
perspective of the design team anyway, was meant to be the constant
which remained across versions/sessions specifically for the purpose
of retaining that collaboration thread. I believe there was some talk
of renaming it the collaboration_id at one point, but there were
already too many terms and too much confusion, so we left it as is.

It might be worth asking Sascha where her work on proper versioning is
going, since it's really the (activity_id, version_id) tuple that
should uniquely identify a specific object, I think.

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.

Perhaps there needs to be some magic built into Sugar which asks an
activity if it can merge (object_a, object_b) so that we can bypass
the default behavior of opening the instances side by side in the case
of a collision.

Eben


> I also wonder what the status of the Presence Service rewrite/removal is.
>
> --Ben
>
> *: I've been testing in 0.82, but I'm not aware of any changes that should
> affect this behavior.
>
>
> _______________________________________________
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
>