| Commit message (Collapse) | Author | Age |
|---|
| ... | |
| |
|
|
|
|
|
| |
Otherwise the client always restarts the resource because of the lost connection.
We currently require this in tests to be able to delete the db, but eventually
we likely want a "disable akonadi" function that shuts resources down,
and keeps clients from restarting them (e.g. via configuration).
|
| | |
|
| |
|
|
|
|
|
|
|
| |
When user gets a Job (from a method call for instance), which is already running
or might have even finished already, they can still append a new Job to the chain
and re-execute it. The Job will internally chain up to the last finished Job, use
it's result and continue from the next Job in the chain. If a Job in the chain is
still running, it will wait for it to finish and pass the result to the next Job
in the chain.
|
| |
|
|
| |
Work for dvratil.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
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.
|
| |
|
|
| |
...and a couple of other fixes.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
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).
|
| |
|
|
|
| |
will allow stateful handling of resource side client-specific caches
in future (e.g. for storing the results of source-side search queries)
|
| | |
|
| | |
|
|
|
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
|
