Frameworks/Akonadi: Difference between revisions

From KDE Community Wiki
(Initial revision)
 
(→‎Akonadi repo structure: Add tests directories)
Line 2: Line 2:


= Akonadi repo structure =
= Akonadi repo structure =
Merge client libraries and server into one repository. Main advantage will be able that we will be able to share more code between server and libraries.
Merge client libraries and server into one repository. Main advantage is that we will be able to share more code between server and libraries.


Proposed structure:
/autotests
/doc
  /src
  /src
  /src/agentbase (libKF5AkonadiAgentBase.so - AgentBase, ResourceBase and other classes related to agents. Needs a better name)
  /src/agentbase (libKF5AkonadiAgentBase.so - AgentBase, ResourceBase and other classes related to agents. Needs a better name)
  /src/agentserver (do we actually use it anywhere? Should it just die?)
  /src/agentserver (do we actually use it anywhere? Should it just die?)
/src/akonadictl (akonadictl utility)
  /src/asapcat (asapcat utility)
  /src/asapcat (asapcat utility)
/src/akonadictl (akonadictl utility)
  /src/common (libKF5AkonadiCommon.so - classes shared between server, core and widgets libraries and other utilities)
  /src/common (libKF5AkonadiCommon.so - classes shared between server, core and widgets libraries and other utilities)
  /src/control (akonadi_control utility)
  /src/control (akonadi_control utility)
  /src/core (libKF5AkonadiCore.so - non-UI classes, only Jobs, models, Monitor etc.)
  /src/core (libKF5AkonadiCore.so - non-UI classes, only Jobs, models, Monitor etc.)
/src/core/jobs
  /src/core/models
  /src/core/models
/src/core/jobs
  /src/interfaces (DBus interfaces)
  /src/interfaces (DBus interfaces)
  /src/qsqlite (Qt's QSQLITE driver fork - better try to upstream it)
  /src/qsqlite (Qt's QSQLITE driver fork - better try to upstream it)
/src/selftest (based on SelfTestDialog class)
/src/server (akonadiserver)
  /src/widgets (libKF5AkonadiWidgets.so - UI classes, depends on core)
  /src/widgets (libKF5AkonadiWidgets.so - UI classes, depends on core)
  /src/widgets/views
  /src/widgets/views
  /src/server (akonadiserver)
  /src/xml (akonadi/xml library)
  /src/selftest (based on SelfTestDialog class)
/tests/akonaditest (akonaditest utility)
/tests/fake (fake classes to be used for testing)
/tests/searchplugin (akonadi_testsearch_plugin)
  /tests/testresource (akonadi_knut_resource)


= Client libraries =
= Client libraries =

Revision as of 11:12, 20 February 2014

This is a list of things I want to do in kdepimlibs/akonadi for Frameworks 5.

Akonadi repo structure

Merge client libraries and server into one repository. Main advantage is that we will be able to share more code between server and libraries.

Proposed structure:

/autotests
/doc
/src
/src/agentbase (libKF5AkonadiAgentBase.so - AgentBase, ResourceBase and other classes related to agents. Needs a better name)
/src/agentserver (do we actually use it anywhere? Should it just die?)
/src/akonadictl (akonadictl utility)
/src/asapcat (asapcat utility)
/src/common (libKF5AkonadiCommon.so - classes shared between server, core and widgets libraries and other utilities)
/src/control (akonadi_control utility)
/src/core (libKF5AkonadiCore.so - non-UI classes, only Jobs, models, Monitor etc.)
/src/core/jobs 
/src/core/models
/src/interfaces (DBus interfaces)
/src/qsqlite (Qt's QSQLITE driver fork - better try to upstream it)
/src/selftest (based on SelfTestDialog class)
/src/server (akonadiserver)
/src/widgets (libKF5AkonadiWidgets.so - UI classes, depends on core)
/src/widgets/views
/src/xml (akonadi/xml library)
/tests/akonaditest (akonaditest utility)
/tests/fake (fake classes to be used for testing)
/tests/searchplugin (akonadi_testsearch_plugin)
/tests/testresource (akonadi_knut_resource)

Client libraries

Status Class Action Comment
TODO AgentBase Merge ObserverV* into Observer There should be "Observer" and "BatchObserver" (not inheriting from each other). BatchObserver would enable the same behavior as ObserverV3 currently {{{4}}} {{{5}}}
TODO AgentSearchInterface Remove addSearch() and removeSearch() methods Search is managed on server now, so we only need search() method to get results. add/removeSearch() are no longer used {{{4}}} {{{5}}}
TODO AgentBase Merge ObserversV* into Observer There should be "Observer" and "BatchObserver" (not inheriting from each other). BatchObserver would enable the same behavior as ObserverV3 currently {{{4}}} {{{5}}}
TODO ChangeMediator Remove ChangeMediator is only used by ItemModifyJob and CollectionModifyJob to invalidate entries in Monitor's EntityCache. Maybe we can find another way to do it. This class was supposed to more, but it was never finished and I don't see other use for it except for the two cases above. {{{4}}} {{{5}}}
TODO Collection Remove deprecated methods {{{4}}} {{{5}}}
TODO CollectionFetchJob Remove deprecated methods {{{4}}} {{{5}}}
TODO CollectionFetchScope Remove deprecated methods {{{4}}} {{{5}}}
TODO CollectionModel Remove {{{4}}} {{{5}}}
TODO CollectionSelectJob Remove? Performs SELECT before FETCH, STORE, APPEND, ... commands. This mimics IMAP behavior, but since we have diverged from IMAP quite a lot by now, we could just change syntax of the commands to include a "COLLECTION" parameter. This could speed up FETCH operation a little {{{4}}} {{{5}}}
TODO CollectionStatisticsModel Remove {{{4}}} {{{5}}}
TODO CollectionView Remove deprecated methods {{{4}}} {{{5}}}
TODO DBusConnectionPool Remove {{{4}}} {{{5}}}
TODO Entity Make it a subclass of AttributeEntity AttributeEntity was introduced to allow sharing code between Tags and Entities. {{{4}}} {{{5}}}
TODO Entity Remove AKONADI_DECLARE_PRIVATE {{{4}}} {{{5}}}
TODO EntityTreeViewStateSaver Remove {{{4}}} {{{5}}}
TODO IndexPolicyAttribute Remove if Baloo Indexer decides to ignore it {{{4}}} {{{5}}}
TODO ItemFetchScope Normalize setter/getter names {{{4}}} {{{5}}}
TODO ItemModel Remove {{{4}}} {{{5}}}
TODO ItemSearchJob Remove deprecated methods {{{4}}} {{{5}}}
TODO ItemSync Make private? Does not seem to be used anywhere {{{4}}} {{{5}}}
TODO ItemView Remove deprecated methods {{{4}}} {{{5}}}
TODO KDSignalBlocker Remove? {{{4}}} {{{5}}}
TODO metatypes.h Remove {{{4}}} {{{5}}}
TODO MimeTypeChecker Maybe remove This class is able to compare mime types, handling aliases, inheritance, etc. AFAIK Volker once told me this should be in Qt 5, so check whether it's there. Might be worth upstreaming, too {{{4}}} {{{5}}}
TODO PersistentSearchAttribute Remove deprecated methods {{{4}}} {{{5}}}
TODO PluginLoader Remove if Qt 5 plugin system is powerful enough {{{4}}} {{{5}}}
TODO ProtocolHelper Share with Server See the Other Plans section below {{{4}}} {{{5}}}
TODO RecursiveItemFetchJob Optimize Emit itemsReceived() signal from underlaying fetch jobs {{{4}}} {{{5}}}
TODO RenameFavoriteDialog Make private? {{{4}}} {{{5}}}
TODO ResourceSettings Remove? {{{4}}} {{{5}}}
TODO SearchCreateJob Remove deprecated methods {{{4}}} {{{5}}}
TODO SelfTestDialog Make a standalone application SelfTestDialog is the only user of QtSQL in client libraries. By making it a stand-alone app, we can get rid of one dependency from libKF5AkonadiCore.so {{{4}}} {{{5}}}
TODO StatisticsProxyModel Remove {{{4}}} {{{5}}}
TODO SubscriptionJob Split to CollectionSubscribeJob and CollectionUnsubscribeJob? Keep the naming consistent {{{4}}} {{{5}}}
TODO TrashFilterProxyModel Remove? Does not seem to be used anywhere {{{4}}} {{{5}}}

Other Plans

Testable Handlers

Does not really depend on Frameworks, can be done at any time. I 'want' to have it done in Frameworks though. Currently we have no way to test Handlers on the server. This would require having a fake DataStore, fake NotificationCollector, fake AkonadiConnection and somehow fake backend for Entities. However, as a result we should be able to send various commands to the handlers and observe whether correct data are stored in database and correct signals are emitted. Big problem with external payload parts, would require a fake ExternalPartManager too.

Shared protocol helper

In a perfect world, we would have Handlers in a shared library and the Handler would be able to parse the command into entities and vice versa. But since the server is using different entities than the client libraries (Akonadi::Server::Collection vs. Akonadi::Collection), this probably won't be possible. However we still should try to share code for handling ImapSets, parsing attributes, payload parts, etc. The first step toward this is to have client jobs use ImapStreamParser.