8 files changed, 606 insertions, 0 deletions

diff --git a/.gitignore b/.gitignore
index 15e63f6..1df13e3 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,2 +1,3 @@
 *.swp
 *.kdev4
+site
diff --git a/docs/clientapi.md b/docs/clientapi.md
new file mode 100644
index 0000000..a2ac18e
--- /dev/null
+++ b/docs/clientapi.md
@@ -0,0 +1,213 @@
+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
+* a notification mechanism to be notified about changes from individual stores
+
+## Requirements/Design goals
+* zero-copy should be possible (mmap support)
+    * Likely only possible until application domain until we rewrite portions of the applications
+    * Most importantly we should hide how the data is stored (in parts, or one mmapped buffer)
+    * Support for mmapped buffers implies that we keep track of the lifetime of the loaded values.
+* property-level on-demand loading
+* streaming support for certain properties (attachments)
+
+## 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), and to have a "language" for queries.
+
+The definition of the domain model directly affects:
+* granularity for data retrievel (email property, or individual subject, date, ...)
+* queriable properties (sender, id, ...)
+* properties used for sorting (10 latest email)
+
+The purpose of these domain types is strictly to be the interface and the types are not meant 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.
+
+### Akonadi Domain Types
+This is a proposed set of types that we will need to evolve into what we actually require. Hierarchical types are required to be able to query for a result set of mixed types.
+
+Items:
+
+* Item
+    * incidence
+        * Event
+        * Todo
+        * Journal
+        * Freebusy
+    * Note
+    * Mail
+    * Contact
+
+Collections:
+
+* Collection
+    * Mail Folder
+    * Calendar
+    * Tasklist
+    * Journal
+    * Contact Group
+    * Address Book
+
+Relations:
+
+* Relation
+    * Tag
+
+## Store Facade
+The store is always accessed through a store specific facade, which hides:
+* store access (one store could use a database, and another one plain files)
+* message type (flatbuffers, ...)
+* indexes
+* syncronizer communication
+* notifications
+
+This abstraction layer allows each resource to separately define how data is stored and retrieved. Therefore tradeoffs can be defined to suit the expected access patters or structure of source data. Further it allows individual resources to choose different technologies as suitable. Logic can still be shared among resources, while keeping the maintenance effort reasonable, by providing default implementations that are suitable for most workloads.
+
+Because the facade also implements querying of indexes, a resource my use server-side searching to fullfill the query, and fallback to local searches when the server is not available.
+
+## Modifications
+Modifications are stored by the client sending modification commands to the syncronizer. The syncronizer is responsible for ensuring that modification are not lost and eventually persistet. A small window exists therefore where a modification is transferred to the syncronizer where a modifications can get lost.
+
+The API consists of the following calls:
+
+* create(domainObject, resource)
+* modify(domainObject, resource)
+* remove(domainObject, resource)
+
+The changeset can be recorded by the domain object adapter while the properties are set, and are then sent to the syncronizer once modify is called.
+
+Each modification is associated with a specific revision, which allows the syncronizer to do automatic conflict resolution.
+
+### Conflict Resolution
+Conflicts can occur at two points in the client:
+
+* While i.e. an editor is open and we receive an update for the same entity
+* After a modification is sent to the syncronizer but before it's processed
+
+In the first case the client is repsonsible to resolve the conflict, in the latter case it's the syncronizer's responsibility.
+A small window exists where the client has already started the modification (i.e. command is in socket), and a notification has not yet arrived that the same entity has been changed. In such a case the syncronizer may reject the modification because it has the revision the modification refers to no longer available.
+
+This design allows the syncronizer to be in control of the revisions, and keeps it from having to wait for all clients to update until it can drop revisions.
+
+## Query System
+The query system should allow for efficient retrieval for just the amount of data required by the client. Efficient querying will be supported by the indexes povided by the resources.
+
+The query always retrieves a set of entities matching the query, while not necessarily all properties of the entity need to be populated.
+
+Queries should be declarative to keep the specification simple and to allow the implementation to choose the most efficient execution.
+
+Queries can be kept open to receive updates as the store changes, and modified to adjust the result set.
+
+### Query
+The query consists of:
+* a declarative set of filters to match the wanted entities
+* the set of properties to retrieve for each entity
+* a limit for the amount of entities to retrieve
+* an offset to retrieve more entities
+
+Queryable properties are defined by the [[Domain Types]] above.
+
+Other Requirements:
+* modifiable: to facilitate adjustments, such as a date-range while scrolling in the mail view.
+* serializable: to persist queries, i.e. to store a "smart folder" query to a config file.
+
+#### Filter
+A filter consists of:
+
+* a property to filter on as defined by the [[Domain Types]]
+* a comparator to use
+* a value
+
+The available comparators are:
+
+* equal
+* greater than
+* less than
+* inclusive range
+
+Value types include:
+
+* Null
+* Bool
+* Regular Expression
+* Substring
+* A type-specific literal value (e.g. string, number, date, ..)
+
+Filters can be combined using AND, OR, NOT.
+
+#### Example
+```
+query =  {
+    offset: int
+    limit: int
+    filter = {
+        and {
+            collection = foo
+            or {
+                resource = res1
+                resource = res2
+            }
+        }
+    }
+}
+```
+
+possible API:
+
+```
+query.filter().and().property("collection") = "foo"
+query.filter().and().or().property("resource") = "res1"
+query.filter().and().or().property("resource") = "res2"
+query.filter().and().property("start-date") = InclusiveRange(QDateTime, QDateTime)
+```
+
+The problem is that it is difficult to adjust an individual resource property like that.
+
+### Usecases ###
+Mail:
+
+* All mails in folder X within date-range Y that are unread.
+* All mails (in all folders) that contain the string X in property Y.
+
+Todos:
+
+* Give me all the todos in that collection where their RELATED-TO field maps to no other todo UID field in the collection
+* Give me all the todos in that collection where their RELATED-TO field has a given value
+* Give me all the collections which have a given collection as parent and which have a descendant matching a criteria on its attributes;
+
+Events:
+
+* All events of calendar X within date-range Y.
+
+Generic:
+* entity with identifier X
+* all entities of resource X
+
+### Lazy Loading ###
+The system provides property-level lazy loading. This allows i.e. to defer downloading of attachments until the attachments is accessed, at the expense of having to have access to the source (which could be connected via internet).
+
+To achieve this, the query system must check for the availability of all requested properties on all matched entities. If a property is not available the a command should be sent to the synchronizer to retrieve said properties. Once all properties are available the query can complete.
+
+Note: We should perhaps define a minimum set of properties that *must* be available. Otherwise local search will not work. On the other hand, if a resource implements server-side search, it may not care if local search doesn't work.
+
+### Data streaming ###
+Large objects such as attachments should be streamable. An API that allows to retrieve a single property of a defined entity in a streamable fashion is probably enough.
+
+### Indexes ###
+Since only properties of the domain types can be queried, default implementations for commonly used indexes can be provided. These indexes are populated by generic preprocessors that use the domain-type interface to extract properties from individual entites.
+
+## Notifications ##
+A notification mechanism is required to inform clients about changes. Running queries will automatically update the result-set if a notification is received.
+
+A notification constist of:
+
+* The latest revision of the store
+* A hint what properties changed
+
+The revision allows the client to only fetch the data that changed.
+The hint allows the client to avoid fetching that it's not interested in.
+A running query can do all of that transparently behind the scenes.
+
+Note that the hints should indeed only hint what has changed, and not supply the actual changeset. These hints should be tailored to what we see as useful, and must therefore be easy to modify.
+
diff --git a/docs/design.md b/docs/design.md
new file mode 100644
index 0000000..9b074b1
--- /dev/null
+++ b/docs/design.md
@@ -0,0 +1,98 @@
+# Goals
+## Axioms
+1. Personal information is stored in multiple sources (address books, email stores, calendar files, ...)
+2. These sources may local, remote or a mix of local and remote
+
+## Requirements
+1. Local mirrors of these sources must be available to 1..N local clients simultaneously
+2. Local clients must be able to make (or at least request) changes to the data in the local mirrors
+3. Local mirrors must be usable without network, even if the source is remote
+4. Local mirrors must be able to syncronoize local changes to their sources (local or remote)
+5. Local mirrors must be able to syncronize remote changes and propagate those to local clients
+6. Content must be searchable by a number of terms (dates, identities, body text ...)
+7. This must all run with acceptable performance on a moderate consumer-grade desktop system
+
+Nice to haves:
+
+1. As-close-to-zero-copy-as-possible for data
+2. Simple change notification semantics
+3. Resource-specific syncronization techniques
+4. Data agnostic storage
+
+Immediate goals:
+
+1. Ease development of new features in existing resources
+2. Ease maintenance of existing resources
+3. Make adding new resources easy
+4. Make adding new types of data or data relations easy
+5. Improve performance relative to existing Akonadi implementation
+
+Long-term goals:
+
+1. Project view: given a query, show all items in all stores that match that query easily and quickly
+
+Implications of the above:
+
+* Local mirrors must support multi-reader, but are probably best served with single-writer semantics as this simplifies both local change recording as well as remote synchronization by keeping it in one process which can process write requests (local or remote) in sequential fashion.
+* There is no requirement for a central server if the readers can concurrently access the local mirror directly
+* A storage system which requires a schema (e.g. relational databases) are a poor fit given the desire for data agnosticism and low memory copying
+
+# Overview
+
+# Types
+## Domain Type
+The domain types exposed in the public interface.
+
+## Buffer Type
+The individual buffer types as specified by the resource. The are internal types that don't necessarily have a 1:1 mapping to the domain types, although that is the default case that the default implementations expect.
+
+## Steps to add support for new types
+* Add new type to applicationdomaintypes.h and implement `getTypenName()`
+* Implement `TypeImplementation<>` for updating indexes etc.
+* Add a type.fbs default schema for the type
+
+## Steps for adding support for a type to a resource
+* Add a TypeAdaptorFactory, which can either register resource specific mappers, or stick to what the default implementation in TypeImplementation provides
+* Add a TypeFacade that injects the TypeAdaptorFactory in the GenericFacade
+* Register the facade in the resource
+* Add synchronization code that creates the relevant objects
+
+# Change Replay
+The change replay is based on the revisions in the store. Clients (and also the write-back mechanism), are informed that a new revision is available. Each client can then go through all new revisions (starting from the last seen revision), and thus update it's state to the latest revision.
+
+# Tradeoffs/Design Decisions
+* Key-Value store instead of relational
+    * `+` Schemaless, easier to evolve
+    * `-` No need to fully normalize the data in order to make it queriable. And without full normalization SQL is not really useful and bad performance wise. 
+    * `-` We need to maintain our own indexes
+
+* Individual store per resource
+    * Storage format defined by resource individually
+        * `-` Each resource needs to define it's own schema
+        * `+` Resources can adjust storage format to map well on what it has to synchronize
+        * `+` Synchronization state can directly be embedded into messages
+    * `+` Individual resources could switch to another store technology
+    * `+` Easier maintenance
+    * `+` Resource is only responsible for it's own store and doesn't accidentaly break another resources store
+    * `-` Inter`-`resource moves are both more complicated and more expensive from a client perspective
+    * `+` Inter`-`resource moves become simple additions and removals from a resource perspective
+    * `-` No system`-`wide unique id per message (only resource/id tuple identifies a message uniquely) 
+    * `+` Stores can work fully concurrently (also for writing)
+
+* Indexes defined and maintained by resources
+    * `-` Relational queries accross resources are expensive (depending on the query perhaps not even feasible)
+    * `-` Each resource needs to define it's own set of indexes
+    * `+` Flexible design as it allows to change indexes on a per resource level
+    * `+` Indexes can be optimized towards resources main usecases
+    * `+` Indexes can be shared with the source (IMAP serverside threading)
+
+* Shared domain types as common interface for client applications
+    * `-` yet another abstraction layer that requires translation to other layers and maintenance
+    * `+` decoupling of domain logic from data access
+    * `+` allows to evolve types according to needs (not coupled to specific applicatoins domain types)
+
+# Risks
+* key-value store does not perform with large amounts of data
+* query performance is not sufficient
+* turnaround time for modifications is too high to feel responsive
+* design turns out similarly complex as akonadi1
diff --git a/docs/index.md b/docs/index.md
new file mode 100644
index 0000000..3019cfd
--- /dev/null
+++ b/docs/index.md
@@ -0,0 +1,17 @@
+# Index
+* Design
+    * Design Goals
+    * Overview
+    * Client API
+    * Storage
+    * Resource
+    * Facade
+    * Logging
+* Extending Akoandi Next
+    * Steps to add support for new types
+    * Steps for adding support for a type to a resource
+
+# Documentation
+This documentation is built using [mkdocs.org](http://mkdocs.org).
+
+Use `mkdocs serve` to run a local webserver to view the docs.
diff --git a/docs/logging.md b/docs/logging.md
new file mode 100644
index 0000000..a88bc0f
--- /dev/null
+++ b/docs/logging.md
@@ -0,0 +1,26 @@
+For debugging purposes a logging framework is required. Simple qDebugs() proved to be insufficient for any non-trivial software. Developers should be enabled to add detailed debug information that allows to analize problems, and users should be enabled to record that information at runtime to debug a problem. The aim is to get away from the situation where developers remove messages because "it's to noisy", and then have to ship a special version with additional debug output to a user to debug a problem, just to then remove the debug output again.
+
+## Requirements
+* runtime configurability of debug level for specific components
+* queriable debug logs. If everything is turned on a *lot* of information will be generated.
+* integration with the system log. It likely makes sense to integrate with the system-log instead of rolling our own solution or use .xsession-errors as dumping ground. In any case, simply logging to the console is not enough.
+* debug information *must* be available in release builds
+* It may make sense to be able to disable certain debug output (configurable per debug level) for certain components at compile time, for performance reasons.
+* Ideally little interaction with stdout (i.e. only warnings). Proper monitoring should happen through:
+    * logfiles
+    * a commandline monitor tool
+    * akonadiconsole
+
+## Debug levels
+* trace: trace individual codepaths. Likely outputs way to many information for all normal cases and likely is only ever temporarily enabled. Trace points are likely only inserted into code fragments that are known to be problematic.
+* debug: Comprehensive debug output. Enabled on demand
+* warning: Only warnings, should always be logged.
+* error: Critical messages that should never appear. Should always be logged.
+
+## Collected information
+Additionally to the regular message we want:
+* pid
+* threadid?
+* timestamp
+* sourcefile + position + function name
+* application name
diff --git a/docs/resource.md b/docs/resource.md
new file mode 100644
index 0000000..847831d
--- /dev/null
+++ b/docs/resource.md
@@ -0,0 +1,42 @@
+The resource consists of:
+
+* the syncronizer process
+* a plugin providing the client-api facade
+* a configuration setting up the filters
+
+# Syncronizer
+* The synchronization can either:
+    * Generate a full diff directly on top of the db. The diffing process can work against a single revision, and could even stop writing other changes to disk while the process is ongoing (but doesn't have to due to the revision). It then generates a necessary changeset for the store.
+    * If the source supports incremental changes the changeset can directly be generated from that information.
+
+The changeset is then simply inserted in the regular modification queue and processed like all other modifications.
+The synchronizer already knows that it doesn't have to replay this changeset to the source, since replay no longer goes via the store.
+
+# Preprocessors
+Preprocessors are small processors that are guaranteed to be processed before an new/modified/deleted entity reaches storage. The can therefore be used for various tasks that need to be executed on every entity.
+
+Usecases:
+
+* Updating various indexes
+* detecting spam/scam mail and setting appropriate flags
+* email filtering
+
+Preprocessors need to be fast, since they directly affect how fast a message is processed by the system.
+
+The following kinds of preprocessors exist:
+
+* filtering preprocessors that can potentially move an entity to another resource
+* passive filter, that extract data that is stored externally (i.e. indexers)
+* flag extractors, that produce data stored with the entity (spam detection)
+
+Filter typically be read-only, to i.e. not break signatures of emails. Extra flags that are accessible through the akonadi domain model, can therefore be stored in the local buffer of each resource.
+
+# Generic Preprocessors
+Most preprocessors will likely be used by several resources, and are either completely generic, or domain specific (such as only for mail).
+It is therefore desirable to have default implementations for common preprocessors that are ready to be plugged in.
+
+The domain types provide a generic interface to access most properties of the entities, on top of which generic preprocessors can be implemented.
+It is that way trivial to i.e. implement a preprocessor that populates a hierarchy index of collections.
+
+# Pipeline
+A pipeline is an assembly of a set of preprocessors with a defined order. A modification is always persisted at the end of the pipeline once all preprocessors have been processed.
diff --git a/docs/storage.md b/docs/storage.md
new file mode 100644
index 0000000..3a8d74a
--- /dev/null
+++ b/docs/storage.md
@@ -0,0 +1,208 @@
+## Store access
+Access to the entities happens through a well defined interface that defines a property-map for each supported domain type. A property map could look like:
+```
+Event {
+  startDate: QDateTime
+  subject: QString
+  ...
+}
+```
+
+This property map can be freely extended with new properties for various features. It shouldn't adhere to any external specification and exists solely to define how to access the data.
+
+Clients will map these properties to the values of their domain object implementations, and resources will map the properties to the values in their buffers.
+
+## Storage Model
+The storage model is simple:
+```
+Entity {
+  Id
+  Revision {
+      Revision-Id,
+      Property*
+  }+
+}*
+```
+
+The store consists of entities that have each an id and a set of properties. Each entity can have multiple revisions.
+
+A entity is uniquely identified by:
+* Resource + Id
+The additional revision identifies a specific instance/version of the entity.
+
+Uri Scheme:
+  akonadi://resource/id:revision
+
+## Store Entities
+Each entity can be as normalized/denormalized as useful. It is not necessary to have a solution that fits everything.
+
+Denormalized:
+* priority is that mime message stays intact (signatures/encryption)
+* could we still provide a streaming api for attachments?
+```
+Mail {
+  id
+  mimeMessage
+}
+```
+
+Normalized:
+* priority is that we can access individual members efficiently.
+* we don't care about exact reproducability of e.g. ical file
+```
+Event {
+  id
+  subject
+  startDate
+  attendees
+  ...
+}
+```
+
+Of course any combination of the two can be used, including duplicating data into individual properties while keeping the complete struct intact. The question then becomes though which copy is used for conflict resolution (perhaps this would result in more problems than it solves).
+
+#### Optional Properties
+For each domain type, we want to define a set of required and a set of optional properties. The required properties are the minimum bar for each resource, and are required in order for applications to work as expected. Optional properties may only be shown by the UI if actually supported by the backend.
+
+However, we'd like to be able to support local-only storage for resources that don't support an optional property. Each entity thus has a "local" buffer that provides default local only storage. This local-only buffer provides storage for all properties of the respective domain type.
+
+Each resource can freely define how the properties are split, while it wants to push as many as possible into the left side so they can be synchronized. Note that the resource is free to add more properties to it's synchronized buffer even though they may not be required by the specification.
+
+The advantage of this is that a resource only needs to specify a minimal set of properties, while everything else is taken care of by the local-only buffer. This is supposed to make it easier for resource implementors to get something working.
+
+### Value Format
+Each entity-value in the key-value store consists of the following individual buffers:
+* Metadata: metadata that is required for every entity (revision, ....)
+* Resource: the buffer defined by the resource (synchronized properties, values that help for synchronization such as remoteId's)
+* Local-only: default storage buffer that is domain-type specific.
+
+## Database
+### Storage Layout
+Storage is split up in multiple named databases that reside in the same database environment.
+
+```
+ $DATADIR/akonadi2/storage/$RESOURCE_IDENTIFIER/$BUFFERTYPE.main
+                                                $BUFFERTYPE.index.$INDEXTYPE
+```
+
+The resource can be effectively removed from disk (besides configuration),
+by deleting the `$RESOURCE_IDENTIFIER` directory and everything it contains.
+
+#### Design Considerations
+* The stores are split by buffertype, so a full scan (which is done by type), doesn't require filtering by type first. The downside is that an additional lookup is required to get from revision to the data.
+
+### Revisions
+Every operation (create/delete/modify), leads to a new revision. The revision is an ever increasing number for the complete store.
+
+#### Design Considerations
+By having one revision for the complete store instead of one per type, the change replay always works across all types. This is especially important in the write-back
+mechanism that replays the changes to the source.
+
+
+### Database choice
+By design we're interested in key-value stores or perhaps document databases. This is because a fixed schema is not useful for this design, which makes
+SQL not very useful (it would just be a very slow key-value store). While document databases would allow for indexes on certain properties (which is something we need), we did not yet find any contenders that looked like they would be useful for this system.
+
+### Requirements
+* portable; minimally: Linux, Windows, MacOS X
+* multi-thread and multi-process concurrency with single writer and multiple readers.
+    * This is required so we don't block clients while a resource is writing and deemed essential for performance and to reduce complexity.
+* Reasonably fast so we can implement all necessary queries with sufficient performance
+* Can deal with large amounts of data
+* On disk storage with ACID properties.
+* Memory consumption is suitable for desktop-system (no in-memory stores).
+
+Other useful properties:
+* Is suitable to implement some indexes (the fewer tools we need the better)
+* Support for transactions
+* Small overhead in on-disk size
+
+### Contenders
+* LMDB
+    * support for mmapped values
+    * good read performance, ok write performance
+    * fairly complex API
+    * Up to double storage size due to paging (with 4k pagesize 4001 bytes provide the worst case)
+    * size limit of 4GB on 32bit systems, virtually no limit on 64bit.  (leads to 2GB of actual payload with write amplification)
+    * limited key-search capabilities
+    * ACID transactions
+    * MVCC concurrency
+    * no compaction, database always grows (pages get reused but are never freed)
+* berkeley db (bdb)
+    * performance is supposedly worse than lmdb (lmdb was written as successor to bdb for openldap)
+    * oracle sits behind it (it has an AGPL licence though)
+* rocksdb
+    * => no multiprocess
+* kyotocabinet http://fallabs.com/kyotocabinet/
+    * fast, low on-disk overhead, simple API
+    * => no multiprocess
+    * GPL
+* hamsterdb
+    * => no multiprocess
+* sqlite4
+    * not yet released
+* bangdb
+    * not yet released opensource, looks promising on paper
+* redis
+    * => loads everything into memory
+    * => not embeddable
+* couchdb
+    * MVCC concurrency
+    * document store
+    * not embeddable (unless we write akonadi in erlang ;)
+* https://github.com/simonhf/sharedhashfile
+    * not portable (i.e. Windows; it's a mostly-Linux thing)
+* http://sphia.org/architecture.html
+    * => no multiprocess
+* leveldb
+    * => no multiprocess
+* ejdb http://ejdb.org/#ejdb-c-library
+    * modified version of kyoto cabinet
+    * => multiprocess requires locking, no multiprocess
+    * Is more of a document store
+    * No updates since September 2013
+* http://unqlite.org
+    * bad performance with large database (looks like O(n))
+    * like lmdb roughly 2*datasize
+    * includes a document store
+    * mmapped ready access
+    * reading about 30% the speed of lmdb
+    * slow writes with transactions
+
+## Indexes
+
+### Index Choice
+Additionally to the primary store, indexes are required for efficient lookups.
+
+Since indexes always need to be updated they directly affect how fast we can write data. While reading only a subset of the available indexes is typically used, so a slow index doesn't affect all quries.
+
+#### Contenders
+* xapian:
+    * fast fulltext searching
+    * No MVCC concurrency
+    * Only supports one writer at a time
+    * If a reader is reading blocks that have now been changed by a writer, it throws a DatabaseModifiedException. This means most of the Xapian code needs to be in wihle (1) { try { .. } catch () } blocks and needs to be able to start from scratch.
+    * Wildcard searching (as of 2015-01) isn't ideal. It works by expanding the word into all other words in the query and that typically makes the query size huge. This huge query is then sent to the database. Baloo has had to configure this expanding of terms so that it consumes less memory.
+    * Non existent UTF support - It does not support text normalization and splitting the terms at custom characters such as '_'.
+* lmdb:
+    * sorted keys
+    * sorted duplicate keys
+    * No FTS
+    * MVCC concurrency
+* sqlite:
+    * SQL
+    * updates lock the database for readers
+    * concurrent reading is possible
+    * Requires duplicating the data. Once in a column as data and then in the FTS.
+* lucenePlusPlus
+    * fast full text searching
+    * MVCC concurrency
+
+## Useful Resources
+* LMDB
+    * Wikipedia for a good overview: https://en.wikipedia.org/wiki/Lightning_Memory-Mapped_Database
+    * Benchmarks: http://symas.com/mdb/microbench/
+    * Tradeoffs: http://symas.com/is-lmdb-a-leveldb-killer/
+    * Disk space benchmark: http://symas.com/mdb/ondisk/
+    * LMDB instead of Kyoto Cabinet as redis backend: http://www.anchor.com.au/blog/2013/05/second-strike-with-lightning/
+
diff --git a/mkdocs.yml b/mkdocs.yml
new file mode 100644
index 0000000..50abdae
--- /dev/null
+++ b/mkdocs.yml
@@ -0,0 +1 @@
+site_name: Akonadi Next