sink - A data access layer handling synchronization, caching and indexing

	Commit message (Collapse)	Author	Age
*	A way to ensure all messages have been processed.	Christian Mollekopf	2015-01-25
\| \| \| \| \|	As queries become reactive this should become less important. We can then just wait until all results become available. For tests it is in either case useful though.
*	Uid index + query using that index.	Christian Mollekopf	2015-01-24
\| \| \| \|	...and a couple of other fixes.
*	debug output	Christian Mollekopf	2015-01-19
\|
*	Use jobs to track progress of write commands.	Christian Mollekopf	2015-01-18
\|
*	Turned synchronizeResource command into a job.	Christian Mollekopf	2015-01-06
\|
*	Buffers wrapped into entity buffer, async command progress tracking.	Christian Mollekopf	2014-12-28
\|
*	Write-Read loop from clientside.	Christian Mollekopf	2014-12-21
\| \| \| \| \| \| \| \| \|	It's a huge hack but starts to show results. Most urgently we need: * reliable command results * the 3 buffers instead of the 1 * A way to implement storage as preprocessor (or a place to impelement it after the preprocessors).
*	use client pid for identifier for now	Aaron Seigo	2014-12-17
\| \| \| \| \|	will allow stateful handling of resource side client-specific caches in future (e.g. for storing the results of source-side search queries)
*	add pipelines (as a sketch only), message ids and message responses	Aaron Seigo	2014-12-16
\|
*	use a dptr, API for sending commands, queue commands until connected	Aaron Seigo	2014-12-16
\|
*	move client classes into akonadi2common and add the base class for resource ↵	Aaron Seigo	2014-12-16
	plugins we can divide up libakonadi2common later once we have a full collection of classes this makes writing code a bit simpler now as we don't have to figuer out which libraries to link against or how class dependencies should look. when we have more infrastructure in place this will mostly become self-evident