| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Some notes:
- Needed to specialize some flatbuffers related functions for serializing QStringList and int
- Removed useless qWarnings in caldav test
- Rename EventSynchronizer -> CalDAVSynchronizer since it also synchronizes Calendars and Todos (and more to come!)
Reviewers: cmollekopf
Tags: #sink
Differential Revision: https://phabricator.kde.org/D12695
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Notes:
- For calendars, only removal is implemented because:
- There is no DavCollectionCreateJob, possibly because there can't be an empty DAV collection
- DavCollectionModifyJob only allows modifying "properties", which we don't use (except for the name, if the name is considered a property)
- Currently, modifying an item with Sink overrides the one on the server, even if the store is not up-to-date
Reviewers: cmollekopf
Tags: #sink
Differential Revision: https://phabricator.kde.org/D12611
|
| | |
|
| |
|
|
| |
..because there is a boatload more to fix.
|
| |
|
|
| |
Differential Revision: https://phabricator.kde.org/D6961
|
| |
|
|
|
|
|
| |
The password (or any other secret), is now cached in the client process
(in-memory only), and delivered to the resource via command.
The resource avoids doing any operations against the source until the
secret is available.
|
| | |
|
| |
|
|
|
|
| |
If we didn't actually do anything we just carry on.
Failing to commit is harmless in that case and committing for every
revision is rather expensive.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Only ever enter error state on non-recoverable errors.
Otherwise:
* Busy state while busy, then go back to online/offline/error.
* If we failed connect during replay/sync we assume we're offline.
* If we failed to login but could connect we have a known error
condition.
* If we succeeded to replay/sync something we are apprently online.
At the core we have the problem that we have no way of telling wether
we can connect to the server until we actually try (network is not
enough: vpns, firewalls, ....). Further the status always reflects the
latest status, so even if we were in an error state, once we retry we go
out of the error state and either end up back in the error state or not.
When aggregating states we have to similarly adjust the state to the
most relevant among the resources. The states are ordered like this:
* Error
* Busy
* Connected
* Offline
|
| | |
|
| |
|
|
|
|
|
|
| |
syncrequest
That way we can do the notification emitting in the synchronizer and it
keeps working even if the login already fails (so the synchronizing code
would never be executed).
|
| |
|
|
|
|
|
|
| |
This will allow us to fold things like progress and sync status directly
into the model. Usecases are mail download progress and folder sync
progress.
Ideally we would also solve the resource/account state through this.
|
| | |
|
| | |
|
| |
|
|
|
| |
We use this frequently when loading conversations, so this results in a
significant preformance improvement.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
If one sync task depends on the previous sync task we want to flush in
between, so we can query for the results of the previous sync request
locally.
If we detect such a dependency we temporarily halt all processing of
synchronization requests until the flush completes, so we can continue
processing.
|
| | |
|
| |
|
|
|
|
|
| |
To have hierarchical debug output we have to pass around something at
run-time, there is no reasonable alternative. Log::Context provides the
identifier to do just that and largely replaces the debug component
idea.
|
| | |
|
| |
|
|
|
| |
... because we really just enqueue the request and then wait for the
notification.
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
Instead of trying to actually flush queues, we send a special command
through the same queues as the other commands and can thus guarantee
that the respective commands have been processed without blocking
anything.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
By concentrating all communication to the source in one place we get rid
of several oddities.
* Quite a bit of duplication since both need access to the
synchronizationStore and the source.
* We currently have an akward locking in place because both classes
access the ync store. This is not easier to resolve cleanly.
* The live of resource implementers becomes easier.
* An implementation could elect to not use changereplay and always do a
full sync... (maybe?)
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is the initial refactoring to improve how we deal with the storage.
It does a couple of things:
* Rename Sink::Storage to Sink::Storage::DataStore to free up the
Sink::Storage namespace
* Introduce a Sink::ResourceContext to have a single object that can be
passed around containing everything that is necessary to operate on a
resource. This is a lot better than the multiple separate parameters
that we used to pass around all over the place, while still allowing
for dependency injection for tests.
* Tie storage access together using the new EntityStore that directly
works with ApplicationDomainTypes. This gives us a central place where
main storage, indexes and buffer adaptors are tied together, which
will also give us a place to implement external indexes, such as a
fulltextindex using xapian.
* Use ApplicationDomainTypes as the default way to pass around entities.
Instead of using various ways to pass around entities (buffers,
buffer adaptors, ApplicationDomainTypes), only use a single way.
The old approach was confusing, and was only done as:
* optimization; really shouldn't be necessary and otherwise I'm sure
we can find better ways to optimize ApplicationDomainType itself.
* a way to account for entities that have multiple buffers, a concept
that I no longer deem relevant.
While this commit does the bulk of the work to get there, the following
commits will refactor more stuff to get things back to normal.
|
| | |
|
| | |
|
| |
|
|
|
| |
We create now only one transaction for the whole sync which is also not
ideal.
|
| | |
|
| | |
|
| |
|
|
| |
version
|
| | |
|
| |
|
