The word "source" implies reading, while in fact access is read/write.
"datastore" avoids that misconception. Writing it in one word emphasizes
that it is single entity.
While renaming, also remove references to explicit --*-property
parameters. The only necessary use today is "--sync-property ?"
and "--datastore-property ?".
--datastore-property was used instead of the short --store-property
because "store" might be mistaken for the verb. It doesn't matter
that it is longer because it doesn't get typed often.
--source-property must remain valid for backward compatility.
As many user-visible instances of "source" as possible got replaced in
text strings by the newer term "datastore". Debug messages were left
unchanged unless some regex happened to match it.
The source code will continue to use the old variable and class names
based on "source".
Various documentation enhancements:
Better explain what local sync is and how it involves two sync
configs. "originating config" gets introduces instead of just
"sync config".
Better explain the relationship between contexts, sync configs,
and source configs ("a sync config can use the datastore configs in
the same context").
An entire section on config properties in the terminology
section. "item" added (Todd Wilson correctly pointed out that it was
missing).
Less focus on conflict resolution, as suggested by Graham Cobb.
Fix examples that became invalid when fixing the password
storage/lookup mechanism for GNOME keyring in 1.4.
The "command line conventions", "Synchronization beyond SyncML" and
"CalDAV and CardDAV" sections were updated. It's possible that the
other sections also contain slightly incorrect usage of the
terminology or are simply out-dated.
cppcheck complains about sub-optimal performance (std::string should be passed
via const reference, not by value). It is not critical here, but for the sake
of getting clean scan results let's fix the issues...
One of the offending methods was never implemented, nor called. Removed.
The Collection class did not initialize all its members. Even if the code
never relied on them being initialized (not checked), it is better to be
safe and predictable, which means initializing all members in the constructor.
Previously, the database field was interpreted as a Collection ID. This adds
logic to allow the database to be interpreted as a folder path. The logic is:
1) If the database is an empty string, pass it through (this is the most
common case as it is interpreted as "use the default folder for the
source type").
2) If the database matches a Collection ID, use the ID (this is the same as
the previous behaviour).
3) If the database matches a folder path name, with an optional leading "/",
use the Collection ID for the matching folder.
4) Otherwise, force a FolderSync to get the latest folder changes from the
server and repeat steps 2 and 3
5) If still no match, throw an error.
Steps 2 and 3 are in the new function lookupFolder. The remaining logic has
been added to the open function. Note that the result is that m_folder (and
hence getFolder()) are always either empty or a Collection ID -- that is as
before so the sync logic itself is unchanged.
A new method, findCollections, fetches the folder list from the server and
creates two maps:
m_collections - store all the information about each collection (folder),
indexed by server collection ID
m_folderPaths - map full folder paths to collection IDs
getDatabases uses this data to returns the folder path, collection ID and a
flag indicating if the folder is the default for that type.
Note 1: getDatabases always asks activesyncd to update the folder list from the
server in order to return up to date information.
Note 2: this depends on a new libeasclient routine:
eas_sync_handler_get_folder_list
This reverts commit 2735273ec60b289c5ec2c49f3eacb9d7d04d5ea1.
With this patch, setting up ActiveSync fails with Google as server.
Needs further investigation.
Also note the explicit g_object_unref() and EASFolderUnref - these
should get replace with SE_GOBJECT_TYPE smart pointers.
This reverts commit 7327b23a4dd31abdc9596916743892402bcffe0c.
Depends on 273527 "ActiveSync: added getDatabases support for fetching
folder list" which has to be reverted.
Previously, the database field was interpreted as a Collection ID. This adds
logic to allow the database to be interpreted as a folder path. The logic is:
1) If the database is an empty string, pass it through (this is the most
common case as it is interpreted as "use the default folder for the
source type").
2) If the database matches a Collection ID, use the ID (this is the same as
the previous behaviour).
3) If the database matches a folder path name, with an optional leading "/",
use the Collection ID for the matching folder.
4) Otherwise, force a FolderSync to get the latest folder changes from the
server and repeat steps 2 and 3
5) If still no match, throw an error.
Steps 2 and 3 are in the new function lookupFolder. The remaining logic has
been added to the open function. Note that the result is that m_folder (and
hence getFolder()) are always either empty or a Collection ID -- that is as
before so the sync logic itself is unchanged.
A new method, findCollections, fetches the folder list from the server and
creates two maps:
m_collections - store all the information about each collection (folder),
indexed by server collection ID
m_folderPaths - map full folder paths to collection IDs
getDatabases uses this data to returns the folder path, collection ID and a
flag indicating if the folder is the default for that type.
Note 1: getDatabases always asks activesyncd to update the folder list from the
server in order to return up to date information.
Note 2: this depends on a new libeasclient routine:
eas_sync_handler_get_folder_list
Updating failed when using Google because the Synthesis engine
tried to read the existing item in order to merge it with
the update. This failed because Google does not implement the
Fetch command.
Pretending to update the item intelligently avoids that. It
also helps to improve performance of updates with Exchange.
The downside is that syncing with local storages which do
not support all ActiveSync fields will cause data loss.
Need to check whether Exchange-only attributes get lost
also when the local storage supports everything, for
example because activesynd unintentionally removes data.
The unconditional change of calling StartDataRead (aka beginSync)
early enough so that ActiveSync can force a slow sync had negative
consequences, because now it was called before the peer was contacted
and credentials were accepted:
- broke the "sync started successfully" logic, resulting in
notifications for syncs which were supposed to be retried silently
(showed up in TestSessionAPIsDummy.testAutoSyncNetworkFailure)
- database dumps were done even if not needed because sync never
starts
Now all backends are called as before unless they explicitly ask for
the early call. The ActiveSync backend does that. The downsides of
that approach do not matter much because syncing will start okay and
dumping of data is typically disable on that side of a local sync.
The testImport test must write all existing items into a file for
comparison. Normally this is done with the backup backend operation,
which does not exist with the ActiveSync backend.
This commit adds a version specifically for that backend. DumpItems()
assumes that item meta data was updated correctly and then reads their
data via ActiveSync[Calendar]Source::readItem() = eas_sync_handler_fetch_item().
Note that this is unnecessarily complex for ActiveSyncCalendarSource:
it reads single VEVENTs, parsed by ActiveSyncCalendarSource, instead
of writing the VCALENDAR produced by activesyncd directly as for ActiveSyncSource.
Will be fixed in the next commit.
activesyncd commit ID:
c788aa464dd866fcb5eaac27533bd53ff1aa5c84
The new ActiveSyncCalendarSource wraps the generic
ActiveSyncSource. It takes single VEVENTs per item and maps them to
ActiveSync items which combine all VEVENTs sharing the same UID.
The code is a combination of MapSyncSource and CalDAVSyncSourc. It
would have been nice to do this without duplicating code, but that
would have implied some pretty heavy core refactoring in code which is
currently in code freeze for SyncEvolution 1.2.
The new backend passes for the same tests as before. It fails for
those cases where ActiveSyncCalendarSource needs to do a partial
update of an ActiveSync item that was not modified on the server. In
that case, the item data is never sent to the client and with the
current activesyncd API it cannot retrieve the data on demand either.
ActiveSyncSource::readItem() needs to be extended. Right now it fails
with "internal error: item data for <eas ID> not available".
activesyncd commit ID:
61285b15a16a52c3c5ad1767047d0ca0ba1f32e8
When testing with "Client::Source::*::testChanges", two different
accounts must be used. Otherwise the two simulated SyncEvolution
clients share the same sync keys and testing fails.
The solution is to switch to a different account, derived by appending
_B to the original account ID, for the second client.
With this fix, the testing continues. But it also needs change in
client-test itself: "testChanges" had a check that all items can be
read, which is not the case for ActiveSync because there unmodified
item data is not available.
activesyncd commit ID:
6300b3ea9184e114b521ef2e5eafda476c836e5c
The command line checks that a source has databases available.
That means that ActiveSyncSource::getDatabases() must at least
return one entry for the default database.
activesyncd commit ID:
6a95a911f2660fab7bea916e3607fa616b4e8b1e
After adding the missing G_END_DECLS in libeassync.h it is possible
to use the header files by specifying the paths explicitly in
configure.
activesyncd commit ID:
3557477ad79c0113a2a3f7ea3b250cf5ff4ac020
Compiles inside SyncEvolution, see README.
Sync session and design outlined in the ActiveSyncSource.h
header file for the main class, ActiveSyncSource.
activesyncd commit ID:
ec8071ae67c107f32305c6d47f176210421c17c7
Patrick Ohly
Graham R. Cobb
Salvatore Iovene