KDE PIM/Akonadi Next/Client API: Difference between revisions

Revision as of 21:00, 1 December 2014

The client API consists of:

A modification API for messages (Create/Modify/Delete)
A query API to retrieve messages
A resource facade to abstract the resource implementation details
A set of standardized domain types

Domain Types

A set of standardized domain types is defined. This is necessary to decouple applications from resources (so a calendar can access events from all resources). The purpose of these domain types are strictly the interface and they are not supposed to be used by applications directly, or to be restricted by any other specifications (such as ical). By nature these types will be part of the evolving interface, and will need to be adjusted for every new property that an application must understand.

Store Facade

The store is always accessed through a store-type specific facade, which hides:

store access (one store could use a database, and another one plain files)
message type (flatbuffers, ...)
indexes

@@ Line 1: / Line 1: @@
+The client API consists of:
+* A modification API for messages (Create/Modify/Delete)
+* A query API to retrieve messages
+* A resource facade to abstract the resource implementation details
+* A set of standardized domain types
-Loading:
+=== Domain Types ===
-* Set load(Query) => A query is executed and a reactive set is returned.
+A set of standardized domain types is defined. This is necessary to decouple applications from resources (so a calendar can access events from all resources). The purpose of these domain types are strictly the interface and they are not supposed to be used by applications directly, or to be restricted by any other specifications (such as ical). By nature these types will be part of the evolving interface, and will need to be adjusted for every new property that an application must understand.
-* TreeSet loadTree(Query) => Additionally to the query a tree structure is available in the reactive set, so support tree models.
-* Future<Message> load(id)
-Modifications:
-* create(Message)
-* modify(Message)
-* delete(id)
-Probably a template mechanism is used to define the message type:
-* template <class T> T load(id)
-Additionally to the wanted type the appropriate facade needs to be chosen based on the buffer type of the query result.
-=== Interface Draft ===
-<pre>
-class DomainObject {
-    virtual void setFoo(QString);
-    virtual QString foo() const;
-};
-class MessageBuffer {
-};
-class DomainAdapter : public DomainObject {
-    virtual void setFoo(QString value)
-    {
-        mBuffer.setFoo(value);
-    }
-    virtual QString foo() const
-    {
-        return mBuffer.foo();
-    }
-    MessageBuffer mBuffer;
-};
-class FacadeFactory {
-    StoreFacade getFacade(const QString &resource);
-}
-class Store {
-    template <class DomainType>
-    static Set<DomainType> load(Query);
-    //Future load(id); => Set with single value
-    template <class DomainType>
-    static TreeSet<DomainType> loadTree(Query)
-    {
-    }
-    //Sync methods for modifications
-    template <class DomainType>
-    static void create(const DomainType &domainObject, const String &resource) {
-        StoreFacade facade =
-    }
-    template <class Type>
-    static void modify(const DomainType &domainObject) {
-    }
-    template <class Type>
-    static void delete(const DomainType &domainObject) {
-    }
-}
-//Translates between message type and domain object
-template <typename ResourceType>
-class StoreFacade {
-};
-</pre>
 === Store Facade ===
@@ Line 87: / Line 12: @@
 * store access (one store could use a database, and another one plain files)
 * message type (flatbuffers, ...)
+* indexes
-* Theoretically we could also include the index, which would allow us to have store specific indexes. However, that way we would require one query per store.
-<pre>
-class StoreFacade {
-    Message load(id);
-    void store(Message);
-}
-</pre>
-=== Message adaptor ===
-A message adaptor interface is implemented for each domain type. This interface has a default implementation for each property like this:
-<pre>
-virtual setFoo(value) {
-  setProperty("foo", value);
-}
-virtual foo() {
-  return property("foo");
-}
-</pre>
-setProperty()/property() must be implemented by every message, resulting in a generic key value store by default (inefficient to load since we have to load everything to load a single value). If the message implementation implements the individual properties it gets efficient loading of values. This way the domain objects can evolve without forcing n message schemas to be updated while we can stil guarantee that all properties work at least local only.