Components

These are the main components of what we will call Project Soylent (or its final name).

GUIs

These will be different ways to interact with the Contact data, though they have similar features. We should probably pick one of these ideas to focus on for the time being (as they have many overlapping goals).

Browser Style

See the mockup.

Buddy List Style

The buddy-list style is designed to replace or be used with the local instant messenger's buddy list. The idea is to have a list of people along with their picture (if available from an address book or something similar), their name, and their online presence information.

Underneath that info is a list of service icons mapping to accounts that are online. This information is provided by [Galago]. The list of icons expand to reveal a Gaim-style buddy list, hereby referred to as the "contact list"

Interaction with the contact list will be similar to that in a standard instant messenger client. Double-clicking a contact will open up a conversation window. It will, however, do this by telling the user's IM client to open the conversation window.

Double-clicking the person entry will bring up a card window showing information on the person. Various options will be available through a context-sensitive menu.

An example of this can be seen in the mockup:

http://osiris.chipx86.com/soylent-list-1.png

Extended Attributes Table

If necessary, we'll maintain a table to track extended attributes which don't easily fit within Evolution-Data-Server's Contact database. This table would be indexed by e-d-s's table's primary key, for easy (on-the-fly) joining/cross-reference. We could also tie in any necessary primary key(s) Beagle uses for its database to associate people across the tables.

Using the databases like this prevents ugly data redundancy (and makes development easier, in general).

In [Galago], every account lives inside a GalagoPerson?. These can be retrieved if you already have a pointer to an account, and it can also be retrieved via a unique ID that in theory should be persistent. These IDs are stored in a local text file database, and galago-daemon? does its best to not lose this information. A custom database could easily keep a reference to this ID and use it for information retrieval.

Contact Metadata Communicators

Travis Reitter? - Note: I have a knack for horribly awkward titles.

These would be small programs or functions which make it easy to relay Contact metadata between yourself and your Contacts.

There are a few approaches to this:

  • Have a daemon (or invoke a regular program from time to time) to request all new metadata from your Contacts
  • Have a daemon (or invoke a regular program from time to time) to offer all new metadata to your Contacts
  • Include a simple way, in the GUI, to send selected Contacts' information to another set of Contacts. This avoids the particularly touchy privacy concern for the above approaches where you may unknowningly pass personal information along to friends-of-friends which are not fully trustworthy.

ChipX86? - I don't know that we need to go this far. There's a standard vcard file format that we can easily build and parse, and we just need to find a way to easily transfer this info to other contacts. We may as well just do this via e-mail, as most real e-mail clients understand vcards and allow for them to easily be included in the addressbook.