Use Sink in docs.

1 files changed, 5 insertions, 5 deletions

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.