Difference between revisions of "Features/Remove Presence Service"

From Sugar Labs
Jump to: navigation, search
(Release Notes)
 
Line 1: Line 1:
 
<noinclude>{{TOCright}}
 
<noinclude>{{TOCright}}
 
[[Category:Feature Accepted 0.90]]
 
[[Category:Feature Accepted 0.90]]
[[Category:Feature|RemovePresenceService]]
+
[[Category:FeatureLanded|RemovePresenceService]]
 
<!-- You can add categories to tie features back to real deployments/schools requesting them, for example  
 
<!-- You can add categories to tie features back to real deployments/schools requesting them, for example  
 
[[Category:Features requested by School Xyz|<Feature Name>]] (the |Feature Name option sorts the entry on the category page under the first letter of <Feature Name>). -->
 
[[Category:Features requested by School Xyz|<Feature Name>]] (the |Feature Name option sorts the entry on the category page under the first letter of <Feature Name>). -->

Latest revision as of 15:05, 5 November 2013

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

We should test both the backend that uses a server (gabble) and the one that doesn't (salut). Sugar will use gabble if it can connect successfully to the server specified in the Network section in the control panel and will fall back to salut if it can't. You can verify which backend is running with the 'ps' command.

Also, we should be testing both with other clients running 0.90 and with clients running earlier versions.

Connection management

Connecting to gabble

  1. Check that the server in the control panel is jabber.sugarlabs.org
  2. Wait a minute
  3. Check that telepathy-gabble is running
  4. Check that some buddies are shown in the neighborhood view

Falling back to salut

  1. Change the server setting to a fake server name
  2. Check that telepathy-gabble isn't running
  3. Check that telepathy-salut is running


Buddy presence

  1. Check that the neighborhood view displays the expected buddies depending on the backend in use and the server configured
  2. Check for the correct nicks and colors
  3. Check that buddies disappear from the view when they disconnect


Activity presence

  1. Start an activity
  2. Share it in the neighborhood
  3. Check other buddies see the activity and the initiator next to it
  4. Make another instance join the activity
  5. Check both buddies appear around the activity

Activity invitations

  1. Start an activity
  2. Invite another buddy to it
  3. Check that an alert appears in the top-left corner and an icon is added to the top level frame
  4. Check in the invited neighborhood view that the activity appears
  5. Join the activity by every of the available methods
  6. Check the activity is properly displayed in both neighborhood views

Friends

  1. Make friend one of the buddies in the neighborhood view
  2. Check it appears in the friends view
  3. Power off the friend's machine
  4. Check it appears as being offline in the friends view
  5. Restart
  6. Check it appears as being offline in the friends view
  7. Start friend machine
  8. Check it appears as online

File transfer

  1. Make sure you have a friend online
  2. From the journal, initiate a transfer
  3. Make the friend accept the transfer
  4. Check that the transfer completed successfully
  5. From the journal, initiate a transfer
  6. Make the friend accept the transfer
  7. Make the friend cancel the transfer
  8. Check the transfer was properly cancelled in both sides

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

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

http://bugs.sugarlabs.org/ticket/416

http://bugs.sugarlabs.org/ticket/2157

http://bugs.sugarlabs.org/ticket/2158

Release Notes

The collaboration code in Sugar has been completely rewritten and the users should notice more reliability and stability. This work will be the base for improvements in the collaboration stack in future releases.

Comments and Discussion