Features/Ad hoc Networking

From Sugar Labs
< Features
Revision as of 12:31, 12 August 2010 by Erikos (talk | contribs) (Created page with '<noinclude>{{TOCright}} SugarAdhocNetworks </noinclude> == Summary == This features removes the need for the Presence Service, meaning that activities and t...')
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search


Summary

This features removes the need for the Presence Service, meaning that activities and the Shell need to interact directly with non-Sugar-specific services such as Telepathy.

Owner

Current status

  • Targeted release: 0.90
  • Last updated: 11/08/2010
  • Percentage of completion: 100%

Detailed Description

The Presence Service caches all the information about presence and provides an API that is closer to what Sugar activities would need. But the presence information is of use only to the Shell, and the simpler API can be provided to activities with means of a library, so there's no real need for a session service that consumes memory, introduces one more layer of interprocess communication and makes activities only work inside the Sugar environment.

This work moves the functionality that the Shell used into the Shell itself and moves the simpler API implementation into the sugar.presence package, and it does so without changing the python activity API.

For Etoys, as it used the Presence Service API directly, a legacy PS will be provided until it is modified to use the telepathy APIs directly. Etoys developers have expressed interest on this work.

Benefit to Sugar

This is the first step in making the collaboration features of Sugar stable and maintainable. The immediate benefit will be that bugs in collaboration will get fixed (yay!) and the total memory footprint will be reduced.

Benefits coming in future releases will be:

  • simplify the code by using Telepathy-GLib via introspection instead of DBus calls,
  • drop the custom extensions and move to standard specs that will allow activities work outside of Sugar,
  • use other protocols such as ICQ, MSN, GSM, etc
  • interact with services not specific to Sugar (ie. public Jabber servers),
  • benefit from improvements to the Telepathy framework from other desktops such as Meego, GNOME and KDE.

Scope

  • sugar: move the presence code and connection management from the PS into neighborhood.py
  • sugar-toolkit: move the code that sets up a shared activity from the PS into sugar.presence.activity
  • sugar-presence-service: remove the connection management code, retrieve activity and contact information synchronously so it's inmediately available when the service is auto-activated.

UI Design

The user experience should be unchanged.

How To Test

Flash at least two XOs with the latest version of Sugar and the latest version of NetworkManager.

Autoconnect

  • connect to an Access Point on one machine and restart the machine

---> the machine does autoconnect with the AP

  • start the machine without having connected to an AP before

---> the machine should autoconnect to ad hoc network 1

  • start machine A and connect to the ad hoc network 6, start machine B without having been connected to an AP before

---> machine B should autoconnect to the ad hoc network 6

Connect both machines to the same channel

---> the buddies should be present on the neighborhood view of the other machine

The learner is connected to channel 11.

Share an activity

---> the shared activity is displayed correctly in the Neighborhod view and the sharing does work

Members

The ad hoc icons in the Neighborhood view do indicate whether the network has members or not, here channel 11 has members.

The ad hoc icons in the Neighborhood view do indicate whether the network has members or not, whether it is used by more than one person. It does not indicate the number of people that are connected though. If the fill color of the ad hoc icon is set then there is at least one person listening.

  • On machine A connect to an ad hoc network. Start machine B which has been connected to an access point before.

---> On machine B it should automatically connect to the access point and the icon representing the ad hoc network machine A is connected to should be colored, the fill color is set.

  • Shut down machine A.

---> after 10-15 minutes the icon representing the ad hoc network machine A is connected to should be uncolored, the fill color is NOT set. This is indicates that there are no members on the network.

Collaborate between XO-1.0 and XO-1.5 without infrastructure

The XO-1.5 and XO-1.0 will see ad hoc networks in his neighborhood view, so it the XO-1.0 can connect to an ad hoc network that has been created by a learner on the XO-1.5.

The XO-1.5 and XO-1.0 will see ad hoc networks in his Neighborhood view, so it the XO-1.0 can connect to an ad hoc network that has been created by a learner on the XO-1.5.

User Experience

No changes.

Dependencies

Will add a dependency on telepathy-mission-control and will need updated versions of telepathy-gabble and telepathy-salut.

Contingency Plan

None necessary, revert to previous release behaviour. I will be able to invest 3-4 days per week until the 0.90 release making sure the feature is more stable than the code it replaces.

Documentation

http://wiki.sugarlabs.org/go/Development_Team/Collaboration_Refactoring

http://wiki.sugarlabs.org/go/Development_Team/Presence_Service_Removal

http://lists.sugarlabs.org/archive/sugar-devel/2010-August/025857.html

Release Notes

TBW

Comments and Discussion

Retrieved from "https://wiki.sugarlabs.org/index.php?title=Features/Ad_hoc_Networking&oldid=55723"