update: the Telepathy: Flexible Communications Framework seems to be related to this functionality. From what I see it provides integration on a much lower level, but at the cost of high implementation complexity. Supporting telepathy might require a complete reqrite of an application. It's not something done by a plugin (please correct me if you feel I'm wrong about that). It seems that only Gnome developers are looking at Telepathy right now. The Banter client is built on top of this. Galago is a desktop presence framework, it allows you to see that the author of an email is online in your IM client using Telepathy. Galago is desktop neutral which is good, but it seems that only Gnome application developers are looking into Galago. Soylent is another project I wasn't aware of that does a idenity integration approach already. It uses libempathy. I Will look into it soon.
update: Guifications is a starting project to send notifications between different applications. Very leightweight protocol. Nice.
The end user is using a IM client, where the he's notified in the chat window that a new email arrived from the same person he's chatting to (even if the IM account is different from the email account). The user may right click this buddy in the IM client, and in the context menu it says you have unread mail from this person, and the context menu will allow you to send email to this person, or call this person using VOIP.
You open a document which has a username in the metadata. You open the metadata, and your wordprocessor notifies you that this user is online on IRC channel #foo and it shows you a menu entry to call this user using VOIP
In your email client you right click the email address. You get a popup showing this person is online with ICQ, and an option to initiate a chat session, and you see the person is logged-on in linkedin.com
To do this we need a standard that all applications can use to exchange information with the daemon.
Communication over Dbus (with the C api) seems to be the most logical choice for interprocess communication in modern desktops(good accessible from different programming languages, etc.).
every app a single channel communication with a daemon - we could just have every app open an IPC channel to every other app on the desktop to check for status on the user. this is tricky for the application programmer: different applications will return information after different times, so a right click context menu has to be changed several times after new information comes in, or the menu will pop-up only after the last application has returned the requested information. Instead of that we chose to have a daemon that collects all the data from all the apps, and every app has a single communication channel to the daemon: request status about a user from the daemon, and you'll get it all in one go. So the application waits for the daemon, and the daemon should have all data already available
a daemon exists that can map different accounts to each other - for example email firstname.lastname@example.org is the same as ICQ #123456789 and is the same as sip: email@example.com . The daemon knows this, so if you request data for ICQ #123456789 you will get data about sip: firstname.lastname@example.org and mail: email@example.com
the user right clicks user firstname.lastname@example.org in a jabber client. The jabber client requests information about email@example.com from the daemon.
The daemon is told (configured by the user, or by some application) about the mapping between email-client:foo@bar and jabber-client: firstname.lastname@example.org . The daemon returns the status information 'New mail from foo@bar' and returns action 'Send mail to foo@bar'
This method is called whenever a client application internally discovers a new identity, or whenever a status message needs to be changed (for a new or existing identity). This may be a new identity for the daemon, or an existing identity
identity - a unique identifier within the client, or within the commonclient, for example email@example.com or firstname.lastname@example.org
class - a machine readable string such as 'mail' to suggestthis identity equals this identity in another client but an equal class'class'. e.g. email@example.com in client 'thunderbird' and firstname.lastname@example.org inclient 'evolution' are the same if they both use the class 'mail'
status - a human readable status message (or empty) such as 1 unread mail from foo@bar or away
this method is called to remove an identity from the daemnon. For example if an email is marked as spam the originating address could be removed from the list handled by the daemon.
this method is called to register actions with the daemon.
actionID - a per-client-unique ID (only within each application this ID should be unique for this action. For example new mail could be ID 0 for thunderbird). Clients that have just a single action can safely use 0 all the time.
actionDescription - a human readable string, other applications will put this in in the context menu. For example send mail to
this method can be called if all status information and actions for this identity are unavailable (for example: IRC user goes offline)
this method can be called if all status information and actions for all identities registered by this client are unavailable (For example: your IRC client is disconnected from the network)
this method is called by an application to retrieve the status of a certain identity
this is called by an application to retrieve all actions for a certain identity
returns a list with the following records:
this is called by an application if the user activated one of the actions retrieved with listidentityactions
this method is called after an application started to indicate the application can handle identities known by a certain class (for example class mail). If an identity with class mail is registered (for example by an addressbook application) without an application, these identities will have the action registered with this function
this method is called if an application knows about certain mappings, for example an addressbook application can register an email address and a jabber account, and register they are the same person
If the daemon method executeidentityaction is called, the daemon will call the method from the application that has to execute the action