On Mon, Jun 29, 2009 at 10:12 PM, Benjamin M. Schwartz<[email protected]> 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 > [email protected] > http://lists.sugarlabs.org/listinfo/sugar-devel > > _______________________________________________ telepathy mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/telepathy
