This roadmap is no mean to be solid in a rock. Things can move and nothing is final. It is just a tool to help us focus our priority work.
Storage abstraction is already in libkopete in SVN.
We should keep that point in mind when refactoring the contact list handling. Some tasks that could really use this pattern. Like deleting a contact. There is no way to be notified if the deletion of a contact went wrong. Most of the contacts tasks are implemented as method 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 object. One task, one object. Easier to maintain too.
The first Strigi use case in Kopete would be history search.
with better name)
The general consensus of everyone was Kopete will going to move to full Telepathy support in a near future. But currently Telepathy spec and Decibel are not mature enough to our needs. But 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 we should split libkopete ? Because some code in libkopete are 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 more easy to maintain, we should split the library which has two distinct missions, manage the application and help to implement the protocol.
Also the plan is to move most of code in Telepathy plugin into the core and make use of Decibel (which currently Telepathy plugin doesn't use).
Allow different people than the current user to use another IM accounts while not bloating the user settings, like a sandbox mode.