Unshare an Activity

[Benjamin M. Schwartz]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hal Murray wrote:
>> This is the problem with your understanding.  A shared activity is
>> _initiated_ by one user, but this user does not _own_ the shared
>> activity.
>>  The user who initially shared the activity can turn off his computer,
>> and the other users can still continue to share with each other.  You
>> can see this with the Chat activity, for example. 
> 
> I'm missing a key idea.
> 
> Some activities have persistent data, say a document.  Another example would 
> be the high score database for a game.

I'm not sure what you mean by "persistent", but I believe I understand
your overall point.  Many activity implementations work internally by
designating one of the participants as a super-node or "server", and then
using that machine as a central point for maintaining canonical copies of
data and synchronizing communications.  A good example of a current
Activity written in this way is Write, in which the main copy of the
document is kept on the server, which is also the machine on which the
instance was initiated.

In the current Sugar design, an Activity like Write that behaves in this
way is considered "broken".  That is, the Sugar UI presents an abstraction
in which all nodes of an Activity are equal, and in principle sharing
continues regardless of who leaves.  This is deliberate, because that's
the desired behavior.  Sugar was designed with an eye toward sharing on a
mesh network, where all network links are unreliable, and sharing must
degrade minimally in the face of connection failures.

In the case of Write, the authors are attempting to reach this point by
writing code to elect a new super-node if the current one leaves the
shared session.  I believe that code has not yet been released.  The last
time I checked, if the initiator of a Write session left the shared
session, the remaining users would still be nominally "sharing" according
to Sugar, but no data would actually be transferred between them.

It's possible that Sugar should grow some UI to indicate if a single group
member is a keystone, and sharing will break if the connection to that
user drops.  That is, however, a fairly ugly thing to try to communicate
to a user, and given a choice we would rather make it unnecessary.

Personally, I've been working on writing a communications library called
Groupthink that ensures that all state is correctly replicated across all
activity instances.  Any Activity that can be written using Groupthink
will automatically be immune to the loss of any single member.

- --Ben
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkmaQuoACgkQUJT6e6HFtqTcjQCePlhnRJiX7uI7eeQPZTG7Ih5w
0BUAn0+f1YQNHI0yQ/PBDTPb2TX+dgjp
=Lk5L
-----END PGP SIGNATURE-----