mesh portal discovery
Benjamin M. Schwartz
bmschwar at fas.harvard.edu
Thu Jan 10 14:29:15 EST 2008
-----BEGIN PGP SIGNED MESSAGE-----
Morgan Collett wrote:
> We'll add some API to PresenceService and sugar.presence, and put some
> signal into Sugar similar to the buddy-left signal to indicate you were
> disconnected, and ensure that the activity gets back into an unshared state.
> If we find the shared activity ID in presence we can attempt to rejoin,
> handing switching of one IP address to another without changing from
> gabble to salut (or vice versa).
> Then Activities will only need to hook the disconnected signal to clean
> up state, if that is necessary.
This is not an acceptable long-term solution. It means that whenever people are
moving about the mesh in a multi-server environment, their activities will
spontaneously disconnect, and possibly reconnect some time later. This is
hugely disruptive to activities with shared state, continuous action, or just
about any other collaboration style. From the users' perspective, it will
inevitably render the sharing system unreliable and frustrating.
As an example, consider two students using Distance (my activity) to measure out
a distance of 15 meters. As they move apart, one of them switches into the
domain of another mesh-portal, and its IP address changes. It suddenly drops
out of the activity, and measurement stops. Some time later, it may rejoin
automatically, at which point the students will have to reinitiate measurement
If IP address switches are triggered automatically, and silently, then they must
be handled automatically, and silently.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
More information about the Devel