Teamgeist

Youness is is leading the development of Teamgeist with the aid of Seif and other contributors.

Teamgeist overview

[Sjoerd Simons's "quick high-level overview of what teamgeist is supposed to be" as of 9 Sept 2009]

So the very high-level use-case is: you're working on a project with a group (one could say a team) and you basically want everyone to have some indication of what other people are doing which is relevant to the project you're working on.

You would give teamgeist some search query which would match zeitgeist events that are relevant to the project. Then the various users join a room which has a d-bus tube and the teamgeist/zeitgeist combination would forward the various events to this room so other people can keep track of them. (The UI for example could show a timeline of what people are/were working on).

Another interesting thing would be that when there are events referring to certain files it would be easy for the other users to get the updated version of the file (or it would automagically be downloaded). Or for users to add a local file to the project, such that teamgeist would update its filters to signal future events on that file to others.

Youness's overview

The Project

What we want with teamgeist is to be able to share zeitgeist events between multiple users.

This should be a secure solution as well as an automated one, so we need to make sure that events would only be shared when they need to be shared. Multiple ways of doing this should be made available to the user.

First, we want to have a single UI to do this, so it needs to be integrated into gnome-zeitgeist instead of having a separate UI for teamgeist. The design would be something like this:

in gnome-zeitgeist, you could right click an event and select "Share with ..." which would allow you to choose which contact or team to share the event with. This would allow for manual sharing of events, which would reinforce security...

You could also have it automatically share some events, You should be able to also select a "permanently share" option. That option could allow you to share all events from the specific application, or all events relating to that single document. If you share all events from a specific application, it should allow you to specify whether you want 'all events' or 'all events matching the current view'.

Gnome-zeitgeist allows you to modify your current view by asking to show only bookmarked items, or items matching a certain timeframe, or events with specific tags, or events from specific applications, or events matching a search string, etc... those settings would be taken into account in order to share events matching 'the current view'. These settings for the gnome-zeitgeist will play the role of our 'search criteria' for our team members.

We should also be able to select multiple events, or to apply this 'share all events matching the current view' from the menu itself.

It would be interesting to also have the possibility to request a document, for example, you could see that X saved a document last night for project P, and you could request that document directly through gnome-zeitgeist, so you could just double click it and the document would open, as if it was a local document.

We have not yet discussed/decided on how this document requesting should be done, whether it would be all automatic, or whether you should request a document and the other user needs to accept it first before the file is transfered.

The implementation

The work to be done on zeitgeist would be to provide a library that could be used by gnome-zeitgeist in order to easily do all this sharing, it would be a bridge between zeitgeist and telepathy and would be used by gnome-zeitgeist directly.

The API is still to be defined, but a rough draft would be to have a single object to which we could call a simple method like 'ShareEvent'. The destination would need to be another object that would represent a person or a team (internally represent a MUC). Another API should be 'RequestDocument' if you want to request a document from another user. A 'ShareDocument' API should also be avaiable to match the 'Requestdocument' one.

The object should also send signals when some events happen, mainly a signal 'EventReceived' and 'DocumentRequested'. Other signals/methods might be needed for stuff like notifying of the progress of the file transfer of a document, listing which contacts are available, their presence, their nickname and their avatar.

The API seems simple enough and should take care of most cases. gnome-zeitgeist should take care of handling all the rest, mainly the pattern matching, which event to send and which to not send, to which team/person send the event, etc.. It (gnome-zeitgeist) should also be the one to store all the config of the user, mainly which events/applications/documents are shared, what are the teams, and who is a member of which team. This will allow libteamgeist (or however the lib will be called) to stay simple and minimal and provide only the bridge between zeitgeist and telepathy.

The organs

A team or a person or a group of people should/would be represented by a MUC (Multi-User Chat) in XMPP, so whenever something needs to be shared, a MUC would be created to hold all the participants of the project.

A Dbus Tube would be created for the MUC and events would be shared through that tube. The Dbus API is to be defined.

The events have a unique URI and we should use that URI as a unique identifier for events being shared. Also note that we do not want to mix teamgeist's events with the local event database, so we'd need to have a database file per team.

We should also have a database for storing which events or search criterias (refered here as 'topic') to send for a specific team!

Event sharing will be done in two modes, first push mode for all current events. So whenever an event matches our topic, we send it to everyone in the MUC.

The second mode will be pull mode for all past events, this means that if a user was offline during a time period, when she comes back online, she will not get the old events unless she specifically requests them (when trying to view them).

The organs

A Dbus Tube would be created for the MUC and events would be shared through that tube. The Dbus API is to be defined.

We should also have a database for storing which events or search criterias (refered here as 'topic') to send for a specific team!

Event sharing will be done in two modes, first push mode for all current events. So whenever an event matches our topic, we send it to everyone in the MUC.

Requirements

1. Bandwidth efficient

2. Secure

3. Fast

4. scalability

5. Share events matching specific criterias

6. No lost events

The uncertainties

Can we just use normal file transfers for document sharing instead of using a tube?

What happens if your 'topic' matches "events from this week" and two weeks later someone tries to access past events? they don't match any topic anymore, yet they are flagged as being shared since they were shared in the past... ?

Should we use the PEP XEP for sharing events instead of dbus?

The uncertainties

Can we just use normal file transfers for document sharing instead of using a tube?

Should we use the PEP XEP for sharing events instead of dbus?

Detailed design

Database

The database will be SQLlite database containing everything we need. We'll have one database per team and it will hold all our events.

The database will contain multiple tables, representing the teams, the topics and the events.

Local events (shared) as well as remote events would be stored in the same database, and would make no differentiation between the local and remote events. This will allow a user to request events from any other user (for catching up on missed events) and any team member would be able to provide the user with the events of the other team members, this way you can catch up to events missed even the original owner of the event is offline (as long as he shared them already with other team members that are online).

The issue with this is obviously data duplication if you have a local shared event, it will appear in both zeitgeist and teamgeist database. Should we find a better solution that doesn't duplicate data?

Table design to be determined

Teams

The teams will also be stored in a database. Originally we would use a MUC to represent a team and the team itself would only be represented by the MUC name@domain as well as a friendly name for easy referencing.

In the future, it would be better to have some other system than MUCs for representing a team (see below for concerns), and the team database would also contain the list of team members and their respective roles.

A team will have a friendly name that can be edited, so we need to be able to send the name of the team to other team members if it ever changes. Only the team owner would be able to change its name.

Using a MUC

Since we would use a MUC to represent a team, the team's name could be set as the description of the MUC, this way it's stored in the server and everyone would always get the latest team name.