<table><tr><td style="">dvratil created this revision.<br />dvratil added a reviewer: kde-pim.<br />Herald added a project: KDE PIM.<br />dvratil requested review of this revision.
</td><a style="text-decoration: none; padding: 4px 8px; margin: 0 8px 8px; float: right; color: #464C5C; font-weight: bold; border-radius: 3px; background-color: #F7F7F9; background-image: linear-gradient(to bottom,#fff,#f1f0f1); display: inline-block; border: 1px solid rgba(71,87,120,.2);" href="https://phabricator.kde.org/D21544">View Revision</a></tr></table><br /><div><strong>REVISION SUMMARY</strong><div><p>This is a first draft of the new API that I'm putting up so everyone<br />
can express their opinions and ideas for improvements. I have<br />
experimentally ported most parts of Akonadi Core library to it and I was<br />
able to run and use Kontact with it, but I want to settle on the API first<br />
before porting the rest.</p>
<p>The purpose of this API is to not remove/obsolete the existing Job-based<br />
API, but to provide an alternative that we can slowly port the codebase<br />
to, but as of now the Job-based API is actually used as the internal<br />
implementation of the new API, so it is not going away any time soon.</p>
<p>This change introduces a factory-like interface that has methods for<br />
various operations (createItem, deleteItem, etc.) that take arguments<br />
for the operation and return a KAsync::Job. KAsync allows chaining<br />
and nesting of jobs (somewhat like the std::future continuation from<br />
Concurrency TS).</p>
<p>The interface has one real implementation called StorageInterface, which<br />
provides integration with the real Akonadi Server, currently wrapping<br />
the good old Akonadi Jobs. When the API matures enough we can flip this<br />
around and have full implementation of the protocol in the<br />
StorageInterface and the Akonadi Jobs simply as wrappers for the async<br />
jobs (and then eventually deprecating the old Job API, but that's for a<br />
very distant future).</p>
<p>The major advantage of this new API is that the interface can be<br />
reimplemented to talk to a mock Akonadi server, either by using a<br />
MockStorageInterface (to be written), or by implementing a custom one<br />
from scratch - this allows users to have complex tests without having to<br />
start a real Akonadi server, as well as making it much easier to prepare<br />
the initial state and conditions for the test.</p>
<p>However, the interface and its implementations are not meant to be used<br />
directly: the "storage.h" file contains a free functions in the<br />
Akonadi namespace that internally only call the corresponding methods on<br />
the interface: this makes it possible to simply swap the default<br />
interface implementation (the one that talks to the real Akonadi server)<br />
for a mock one in a single place and make it apply to all client code<br />
without the code being aware of this.</p>
<p>Currently the Interface is missing abstraction for the Monitor which as<br />
of now interacts with the Server by directly creating and receiving raw<br />
Akonadi Protocol messages - I don't have a good clean solution for this<br />
yet without polluting the Interface with API that is otherwise internal<br />
to the Monitor.</p></div></div><br /><div><strong>REPOSITORY</strong><div><div>R165 Akonadi </div></div></div><br /><div><strong>REVISION DETAIL</strong><div><a href="https://phabricator.kde.org/D21544">https://phabricator.kde.org/D21544</a></div></div><br /><div><strong>AFFECTED FILES</strong><div><div>CMakeLists.txt<br />
src/core/CMakeLists.txt<br />
src/core/interface.cpp<br />
src/core/interface.h<br />
src/core/interface/storageinterface.h<br />
src/core/jobs/tagmodifyjob.cpp<br />
src/core/session.cpp<br />
src/core/session.h<br />
src/core/storage.cpp<br />
src/core/storage.h</div></div></div><br /><div><strong>To: </strong>dvratil, kde-pim<br /><strong>Cc: </strong>dvasin, rodsevich, winterz, vkrause, mlaurent, knauss, dvratil<br /></div>