D21544: [RFC] First draft of the new async client API to interact with Akonadi

[Daniel Vrátil]

dvratil created this revision.
dvratil added a reviewer: kde-pim.
Herald added a project: KDE PIM.
dvratil requested review of this revision.

REVISION SUMMARY
  This is a first draft of the new API that I'm putting up so everyone
  can express their opinions and ideas for improvements. I have
  experimentally ported most parts of Akonadi Core library to it and I was
  able to run and use Kontact with it, but I want to settle on the API first
  before porting the rest.
  
  The purpose of this API is to not remove/obsolete the existing Job-based
  API, but to provide an alternative that we can slowly port the codebase
  to, but as of now the Job-based API is actually used as the internal
  implementation of the new API, so it is not going away any time soon.
  
  This change introduces a factory-like interface that has methods for
  various operations (createItem, deleteItem, etc.) that take arguments
  for the operation and return a KAsync::Job. KAsync allows chaining
  and nesting of jobs (somewhat like the std::future continuation from
  Concurrency TS).
  
  The interface has one real implementation called StorageInterface, which
  provides integration with the real Akonadi Server, currently wrapping
  the good old Akonadi Jobs. When the API matures enough we can flip this
  around and have full implementation of the protocol in the
  StorageInterface and the Akonadi Jobs simply as wrappers for the async
  jobs (and then eventually deprecating the old Job API, but that's for a
  very distant future).
  
  The major advantage of this new API is that the interface can be
  reimplemented to talk to a mock Akonadi server, either by using a
  MockStorageInterface (to be written), or by implementing a custom one
  from scratch - this allows users to have complex tests without having to
  start a real Akonadi server, as well as making it much easier to prepare
  the initial state and conditions for the test.
  
  However, the interface and its implementations are not meant to be used
  directly: the "storage.h" file contains a free functions in the
  Akonadi namespace that internally only call the corresponding methods on
  the interface: this makes it possible to simply swap the default
  interface implementation (the one that talks to the real Akonadi server)
  for a mock one in a single place and make it apply to all client code
  without the code being aware of this.
  
  Currently the Interface is missing abstraction for the Monitor which as
  of now interacts with the Server by directly creating and receiving raw
  Akonadi Protocol messages - I don't have a good clean solution for this
  yet without polluting the Interface with API that is otherwise internal
  to the Monitor.

REPOSITORY
  R165 Akonadi

REVISION DETAIL
  https://phabricator.kde.org/D21544

AFFECTED FILES
  CMakeLists.txt
  src/core/CMakeLists.txt
  src/core/interface.cpp
  src/core/interface.h
  src/core/interface/storageinterface.h
  src/core/jobs/tagmodifyjob.cpp
  src/core/session.cpp
  src/core/session.h
  src/core/storage.cpp
  src/core/storage.h

To: dvratil, kde-pim
Cc: dvasin, rodsevich, winterz, vkrause, mlaurent, knauss, dvratil
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20190602/0ffd400f/attachment.html>