8 files changed, 32 insertions, 32 deletions

diff --git a/docs/akonadish.md b/docs/akonadish.md
index b144dba..9884169 100644
--- a/docs/akonadish.md
+++ b/docs/akonadish.md
@@ -1,7 +1,7 @@
-The akonadi shell is the primary interaction point from the commandline. It can be used for debugging, maintenance and scripting.
+The sink shell is the primary interaction point from the commandline. It can be used for debugging, maintenance and scripting.
 
 The syntax is:
-  `akonadish COMMAND TYPE ...`
+  `sinksh COMMAND TYPE ...`
 
 # Commands
 
@@ -23,7 +23,7 @@ Drops all caches of a resource but leaves the config intact. This is useful whil
 
 ## synchronize
 Allows to synchronize a resource. For an imap resource that would mean that the remote server is contacted and the local dataset is brought up to date,
-for a maildir resource it simply means all data is indexed and becomes queriable by akonadi.
+for a maildir resource it simply means all data is indexed and becomes queriable by sink.
 
 Eventually this will allow to specify a query as well to i.e. only synchronize a specific folder.
 
@@ -31,24 +31,24 @@ Eventually this will allow to specify a query as well to i.e. only synchronize a
 Provides the same contents as "list" but in a graphical tree view. This was really just a way for me to test whether I can actually get data into a view, so I'm not sure if it will survive as a command. For the time being it's nice to compare it's performance to the QML counterpart.
 
 # Setting up a new resource instance
-akonadi_cmd is already the primary way how you create resource instances:
+sink_cmd is already the primary way how you create resource instances:
 
-  `akonadish create resource org.kde.maildir path /home/developer/maildir1`
+  `sinksh create resource org.kde.maildir path /home/developer/maildir1`
 
 This creates a resource of type "org.kde.maildir" and a configuration of "path" with the value "home/developer/maildir1". Resources are stored in configuration files, so all this does is write to some config files.
 
-  `akonadish list resource`
+  `sinksh list resource`
 
 By listing all available resources we can find the identifier of the resource that was automatically assigned.
 
-  `akonadish synchronize org.kde.maildir.instance1`
+  `sinksh synchronize org.kde.maildir.instance1`
 
 This triggers the actual synchronization in the resource, and from there on the data is available.
 
-  `akonadish list folder org.kde.maildir.instance1`
+  `sinksh list folder org.kde.maildir.instance1`
 
 This will get you all folders that are in the resource.
 
-  `akonadish remove resource org.kde.maildir.instance1`
+  `sinksh remove resource org.kde.maildir.instance1`
 
 And this will finally remove all traces of the resource instance.
diff --git a/docs/applicationdomaintypes.md b/docs/applicationdomaintypes.md
index 4baf317..798fa13 100644
--- a/docs/applicationdomaintypes.md
+++ b/docs/applicationdomaintypes.md
@@ -22,7 +22,7 @@ This is a proposed set of types that we will need to evolve into what we actuall
         * Mail
         * Contact
         * Collection
-            * Akonadi Resource
+            * Sink Resource
             * Mail Folder
             * Calendar
             * Todolist
@@ -32,19 +32,19 @@ This is a proposed set of types that we will need to evolve into what we actuall
             * Tag
             * Contact Group
             * Thread
-    * Akonadi Resource
+    * Sink Resource
         * Maildir Resource
 
 #### Properties
 ```no-highlight
-Entity: The smallest unit in the akonadi universe
-    id: unique identifier in the akonadi storage. Not persistant over db recreations and can therefore only be referenced from within the akonadi database.
+Entity: The smallest unit in the sink universe
+    id: unique identifier in the sink storage. Not persistant over db recreations and can therefore only be referenced from within the sink database.
 ```
 ```no-highlight
 Domain Object:
     uid: unique identifier of the domain object.
     revision: revision of the entity
-    resource: reference to AkonadiResource:id of the parent resource.
+    resource: reference to SinkResource:id of the parent resource.
 ```
 ```no-highlight
 Event:
@@ -61,7 +61,7 @@ Mail:
     mimeMessage: A string containing the path to the mime message
 ```
 ```no-highlight
-Akonadi Resource:
+Sink Resource:
     type: The type of the resource.
     name: The name of the resource.
 ```
@@ -75,7 +75,7 @@ Some domain objects reference others, and that is often used to build hierarchie
 Examples are folder hierachies, tags, todo hierarchies, mail threads, contact groups, etc.
 
 These references can be built on two levels:
-* On the akonadi entity level: The referenced object *must* be available in local storage, and we're only linking to that specific instance. If the referenced entity is removed, the reference breaks. The reference always only references a single akonadi entity.
+* On the sink entity level: The referenced object *must* be available in local storage, and we're only linking to that specific instance. If the referenced entity is removed, the reference breaks. The reference always only references a single sink entity.
 * On the domain object level: The reference can remain also if no object currently matches the reference. The reference automatically applies to new entities containing an object with the referenced uid. More than one entity can be matched if they contain the same domain object.
 
 #### Examples
@@ -84,7 +84,7 @@ The following hierachies exist among others:
 * Parent Collection
     * Given by the source (path of the folder in IMAP)
     * Parent folder "owns" the sub entity
-    * Link exists on the akonadi entity level: We specify where the entity lives, this MUST always be a single parent entity.
+    * Link exists on the sink entity level: We specify where the entity lives, this MUST always be a single parent entity.
 * Subtodos
     * Given by the todo itself
     * Not necessarly owning (though often implemented as such, similar to threading)
diff --git a/docs/design.md b/docs/design.md
index 772bd65..4451b49 100644
--- a/docs/design.md
+++ b/docs/design.md
@@ -40,7 +40,7 @@ Implications of the above:
 # Overview
 
 ## Client API
-The client facing API hides all akonadi internals from the applications and emulates a unified store that provides data through a standardized interface. 
+The client facing API hides all Sink internals from the applications and emulates a unified store that provides data through a standardized interface. 
 This allows applications to transparently use various data sources with various data source formats.
 
 ## Resource
@@ -98,4 +98,4 @@ Each resource has an internal pipeline of preprocessors that can be used for tas
 * 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
+* design turns out similarly complex as Akonadi
diff --git a/docs/extendingakonadi.md b/docs/extending.md
index fe38e87..fe38e87 100644
--- a/docs/extendingakonadi.md
+++ b/docs/extending.md
diff --git a/docs/resource.md b/docs/resource.md
index 0988535..defbf9a 100644
--- a/docs/resource.md
+++ b/docs/resource.md
@@ -31,7 +31,7 @@ The following kinds of preprocessors exist:
 * passive preprocessors, that extract data that is stored externally (i.e. indexers)
 * flag extractors, that produce data stored with the entity (spam detection)
 
-Preprocessors are typically 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.
+Preprocessors are typically read-only, to i.e. not break signatures of emails. Extra flags that are accessible through the sink domain model, can therefore be stored in the local buffer of each resource.
 
 ## Requirements
 * A preprocessor must work with batch processing. Because batch-processing is vital for efficient writing to the database, all preprocessors have to be included in the batch processing.
diff --git a/docs/storage.md b/docs/storage.md
index 794a739..4852131 100644
--- a/docs/storage.md
+++ b/docs/storage.md
@@ -34,7 +34,7 @@ The additional revision identifies a specific instance/version of the entity.
 
 Uri Scheme:
 ```
-akonadi://resource/id:revision
+sink://resource/id:revision
 ```
 
 ## Store Entities
@@ -138,7 +138,7 @@ Resources...
 
 Queries...
 
-* Copy the requested property to /tmp/akonadi2/client_files/ and provide the path in the property
+* Copy the requested property to /tmp/sink/client_files/ and provide the path in the property
 * The file is guaranteed to exist for the lifetime of the query result.
 
 Clients..
@@ -149,7 +149,7 @@ For writing:
 
 Clients..
 
-* Request a path from akonadi2 and store the file there.
+* Request a path from sink and store the file there.
 * Store the path of the written file in the property.
 
 Resources..
@@ -218,7 +218,7 @@ Other useful properties:
 * couchdb
     * MVCC concurrency
     * document store
-    * not embeddable (unless we write akonadi in erlang ;)
+    * not embeddable (unless we write sink in erlang ;)
 * https://github.com/simonhf/sharedhashfile
     * not portable (i.e. Windows; it's a mostly-Linux thing)
 * http://sphia.org/architecture.html
diff --git a/docs/terminology.md b/docs/terminology.md
index 9da8851..1826bec 100644
--- a/docs/terminology.md
+++ b/docs/terminology.md
@@ -1,11 +1,11 @@
 Consistent, agreed-upon terminology is key to being able to work together efficiently on a complex software project such as this, particularly as we are building on the earlier Akonadi efforts which itself has established terminology. You can find the current glossary here.
 
-It is recommended to familiarize yourself with the terms before going further into the design of Akonadi-next as it will make things clearer for you and easier to ask the questions you have in a way that others will understand immediately.
+It is recommended to familiarize yourself with the terms before going further into the design of Sink as it will make things clearer for you and easier to ask the questions you have in a way that others will understand immediately.
 
-## Glossary of Akonadi-Next Terms
+## Glossary of Sink Terms
 * akonadi1: The current akonadi implementation that uses a central server and an SQL database
-* akonadi-next: This is the codename for the project. In the long run this is supposed to be folded into regular akonadi, so we will never release a product called akonadi-next.
-* client: any application which accesses data using akonadi
+* Sink: This is the name for the project.
+* client: any application which accesses data using Sink
 * entity: The atomic unit for a given type of data. An email is an entity; an email folder is an entity; a calendar event is an entity; a contact is an entity; etc. Different kinds of entities may have their own data structure, but conceptually they are equivalent in most other ways.
 * revision: A version of the store. One entity may have multiple revisions in a store, representing (for instance) the local state and the synchronized state of the entity.
 * source: The canonical data set, which may be a remote IMAP server, a local iCal file, a local maildir, etc.
@@ -20,6 +20,6 @@ It is recommended to familiarize yourself with the terms before going further in
 * command queue: A queue of commands kept by the synchronizer to ensure durability and, when necessary, replayability
 * notification: A message sent from a synchronizer to inform the client of a change in the store
 * domain object: An application domain object, i.e. an event.
-* domain type: The type of a domain object. i.e. Akonadi2::ApplicationDomain::Event
+* domain type: The type of a domain object. i.e. Sink::ApplicationDomain::Event
 * buffer: The buffers used by the resources to persist data in the datastore.
 * buffer type: The individual buffer types as specified by the resource. These 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.
diff --git a/mkdocs.yml b/mkdocs.yml
index fd892f5..21f9471 100644
--- a/mkdocs.yml
+++ b/mkdocs.yml
@@ -1,4 +1,4 @@
-site_name: Akonadi Next
+site_name: Sink
 pages:
 - Home: index.md
 - Terminology: terminology.md
@@ -7,8 +7,8 @@ pages:
 - Storage: storage.md
 - Logging: logging.md
 - "Client API": clientapi.md
-- akonadish: akonadish.md
+- sinksh: sinksh.md
 - "Application Domain Types": applicationdomaintypes.md
-- "Extending Akonadi": extendingakonadi.md
+- "Extending Sink": extending.md
 - Building: building.md
 theme: readthedocs