At GUADEC, a number of the people-centric software people (from Soylent, Banter, Empathy, Telepathy, Mugshot/Online Desktop) got together to discuss some issues around integrating our work.
Here are some ideas for the short-term implementation, to get us rolling on integration. Many of these based on other peoples' ideas, but here's how I think it can all fit together. This isn't exhaustive, and mainly focuses on issues related to people-centric apps. Basic Architecture ================== [Desktop People Apps] <-> [Empathy] <-> [e-d-s] <-> [Online desktop server] Desktop people apps will use Empathy to abstract cohesive People objects. Right now, Empathy just handles Telepathy contacts (dynamic people metadata), but Xavier has expressed interest in integrating e-d-s support (static people metadata). For a useful People object, you really need both the static and dynamic metadata. Simply connecting e-d-s EContacts with live IM accounts will be a great first start, and Empathy should serve as a good way to access additional metadata as we add additional sources. Offline Functionality ===================== One important aspect of this system (especially from the embedded/mobile device perspective) is the need for graceful degradation/useful operation without an Internet connection. I think, and I believe we largely agreed in the discussion, that we care mainly about the use cases with intermittent network connectivity as opposed to use cases of rare network connectivity. If you rarely have an Internet connection, the Online Desktop won't be very interesting to you. Without an Internet connection, we'll want to have a local cache for any manual changes to our address book. This is for the sort of use case that someone gives you their business card, and you want to add them to your address book immediately, without having to wait for an Internet connection. As much as possible, I would like to avoid manual metadata entry. The social networking model works very well for this. That way, you fill out your own details once, mutually connect with people, and that's it. Each time your friends update their profiles, your address book is updated automatically. This substantially beats the old desktop equivalent, where you have to manually enter and synchronize your contacts' full profiles on each of your devices. For the above case, I'd much rather you enter the person's email address (or other ID), and it trigger a "friend request" when you connect to the Internet next time. That way, you just enter a short string once, and then get access to their full profile. Evolution Data Server will make a decent local cache. Most Gnome apps that care about an address book right now use e-d-s already, and since it's based on VCards, it's fairly extensible. I think we all agree it's not perfect, but it's good enough in the short term. And most of the flaws I've seen/heard of from other people have been implementation (some completely internal), not fundamental design problems. Synchronization and Merging =========================== Upon connection to the Internet, a daemon will download address book changes from the Online Desktop provider and merge them into the local cache (e-d-s). Since the Online Desktop server will be the master, it will overwrite any older metadata (and probably delete any metadata not in the Online Desktop data source). The only metadata that should be pushed from the local cache toward the Online Desktop address book are 1. edits to your own profile and 2. people to add as contacts. We don't want to expose the option to edit other peoples' metadata, because that adds a lot of boring information we probably don't want to edit anyhow. And you are the most authoritative source of your metadata, so no one would have the right to edit yours (nor would they want to for any non-malicious case). There are some exceptions (where you would want to have private metadata for a specific person, like your own private notes about that person), but I'm trying to generalize to get the bigger picture. Privacy and Data Ownership ========================== Because the Online Desktop server software will be open source, anyone will be able to run their own server. Distros may want to run their own, for instance. And completely independent groups/companies could host as well. You will have the option to choose your provider (including a server of your own), or none at all (if you want your desktop to be in "classic mode", without the Online Desktop integration). We hope this should settle any privacy/data ownership concerns. I'm betting that most people won't be terribly concerned about this, but I think this is a good solution. You probably won't want to switch Online Desktop providers willy-nilly (since this involves a lot more state than a switch between email or web hosting providers), but it hopefully shouldn't be too painful. And since different Online Desktop providers should synchronize to a certain degree (in the same way that one instance would synchronize with Facebook, Flickr, etc.), we should be able to avoid fragmenting social networks, etc. As far as associating ownership/transmission policies with (meta)data, I like the idea of the following levels: private, friends, family, public. That seems like the simplest usable classification scheme. If it seems useful, I would also suggest a "business" category, which be between "family" and "public". This ordering is mostly in order from least to most public, but there are so many exceptions that it may be best to just consider them an unordered list. We may want to have a "default license" to apply to anything public. For legal reasons, this would probably have to default to strict copyright, but it would be wonderful to be able to set this in one location (with the ability to adjust on an individual content basis as well). This would hopefully reduce the barriers to releasing generated content under copyleft licenses for regular people. Changes involved ================ 1. Empathy needs support for Evolution Data Server contacts. I'm planning to work with Xavier on this as soon as I finish and clean up the Empathy <-> e-d-s integration I do within Soylent. By then I should have a good idea of how they should work together and a decent API. 2. We need an Online Desktop preferences applet (mainly to choose your Online Dekstop provider (if any)). 3. Something (probably the Online Desktop preferences applet) needs to set up any private/public keys and Gnome Keyring Manager entr(ies). 4. A daemon to initiate and perform data synchronization and merging. This could be a modified version of eds-sync (though that requires a special version of e-d-s (the dbus port, I believe)). Maybe Conduit could be use for anything beyond the address book - though I believe it already handles that too. How should these two work together? 5. The Online Desktop server software needs to be generalized, installable on individual machines, etc. However, this is really mid- to long-term, and we'd be much better off using the instance that Havoc and Owen are setting up for Gnome for testing/development until it's ready for wider release. Thoughts? :) -Travis _______________________________________________ desktop-devel-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/desktop-devel-list
