Soylent as a Person Information Abstraction Layer

Currently we seem to focus on how to present "persons" to users. I don't think this is the most important thing we should be doing. What we should do instead is offer some unique point of information on Buddies, think of this like HAL allows you to get lots of information on all hardware components in your system.

The problem

Let's start with a hypothetical called BuddyInformation?. This is just some simple CLI application that allows the user to retrieve all possible information on a buddy. Today, this application should know how to talk to EDS to fetch e.g. address information from the buddy, or retrieve email addresses. It should be able to talk to Galago to figure out the presence state of the buddy. It can query Gaim to get information from e.g. the MSN Member Directory (this is not possible yet, but it could be). The application could get some information from Beagle too, etc.

Now imagine the user is not using Gaim at all, but uses Gossip (Gaim is no member of the Gnome platform, so you can't expect the user to use it). Or the user uses Thunderbird, because he was used to it while he was working under Windows and he's a newbie Linux desktop user. Or maybe he's one of those guys that stick with Mutt and got addressbooks in ~/.addressbook.

The developer of BuddyInformation? would have to know a lot of API's, and write a lot of parsing code himself to allow his application to fetch information from different sources.

A possible solution

Unification of person information retrieval from multiple backends. This problem could be solved by Soylent. Soylent could be something like HAL: provide other applications with information, regardless where it comes from. Just like in HAL, where a block device must have certain properties, and may have some others, imagine we define a buddy object which must have these properties:

  • Name
  • First Name
  • Nickname

and may have other properties like

  • Blog URI
  • Presence (online/busy/away/whatever)
  • Email address

and others. Of course these lists are not complete.

We could, next to "standard" properties, also have some X- properties, like used in SMTP or MIME. An example of this could be X-Evolution-UID if we fetch information on the buddy from EDS. This way it's easier for the client application to talk to EDS on this buddy later, it should not do all queries to find the buddy.

Then we got a tree:

  • Buddies/
    • /Friends/
      • /School/
        • /John Doe
        • /Foo Bar
      • /Elvis Presly
    • /Work/
      • /Gnome/
        • /Some Guy
        • /Some Girl
      • /My Boss
    • /Family/
      • /Grand Daddy

etc. Buddies are grouped together, but can also be a member of several groups (e.g. a Gnome hacker you work with can also be a real friend). All these buddies got several properties.

Buddies can also have inter-buddy relationships (think FOAF).

Soylent fetches buddy properties from several sources using backends. This way we are not forced to write and maintain e.g. a Thunderbird backend, but other people can do this. These backends are just simple .so files implementing a well defined module API (as done in lots of other progrmas already).

Implementation questions

  • Should we use a daemon like HAL does, or is a shared library that reads data at runtime sufficient? HAL is daemon based because it should be able to send events/notifications to its clients, something we don't need.
  • Do we store data ourself, or do we only gether data from other sources? Relational information is not stored in any desktop application yet AFAIK, so this should be stored by us.
  • Do we provide information pushing? (e.g. Gaim -> Soylent -> EDS) I don't think this is a good idea, it'd make a lot of things more difficult.
  • To create a tree, should we get this information from another source, or should we store it ourself?

What would be nice: have a "pod" with all contacts in it, then create the tree using "symlinks" to the "pod". This way it's very easy to move people around in the tree (not database/memory intensive), and it's easy to give one person several places inside the tree (eg friend and coworker)

Sample backends

  • EDS
  • Thunderbird addressbook
  • ~/.addressbook parser
  • Galago
  • MSN Member Directory parser
  • Some mDNS based thing to retrieve information on a person from other clients in the network. This can be very usefull in a company workspace, but does need privacy protection etc. Contact information sharing should be disabled by default.
  • F-Spot (find pictures depicting the buddy)
  • Beagle (when using this, it could replace the F-Sport backend)

Sample applications

  • A buddy browser as VFS, e.g. in Nautilus, allowing the user to browse his buddy tree. Currently I'm writing a GnomeVFS module that allows something like this based on EDS data, as a proof of concept. First stage done, further tweaking can start. See here
  • Everything described here