This roadmap is not meant to be rock solid. Things can move and nothing is final. It is just a tool to help us focus our priorities.
Storage abstraction is already in libkopete in SVN.
See more on IDENTITY_REFACTORY in kopete svn.
We should keep that point in mind when refactoring the contact list handling. Some tasks could really use this pattern, like deleting a contact. Currently there is no way to be notified if the deletion of a contact went wrong. Most of the contacts tasks are implemented as methods of some classes, like Kopete::Contact::deleteContact which return.....void.
Using the Command pattern allow us to use signals for notification and encapsulate tasks into proper objects. One task, one object. Easier to maintain too.
There exist a working implementation including some samples in extragear now.
The first Strigi use in Kopete would be the history search.
We could use for history and for the contact list. Then history's Strigi would index the Akonadi backend.
Allow people other than the current user to use another IM account while not bloating the user settings, like a sandbox mode.
with a better name)
The general consensus of everyone was that Kopete will to move to full Telepathy support in the near future. But currently the Telepathy spec and Decibel are not mature enough for our needs. We need to prepare for that move because most people want to keep a BC during Kopete 1.0 period.
Will is going to look into making our protocols available as connection manager.
Why should we split libkopete? Because some code in libkopete is related to the application itself (and plugins) and others are related to protocol implementation. If we want to be more efficient and have a core library easier to maintain, we should split the library to have two distinct missions, manage the application, and help to implement the protocols.
The plan is also to move most of code in Telepathy plugin into the core and make use of Decibel (which the Telepathy plugin doesn't use).