maryjane
/
syncevolution
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity
syncevolution/src/backends/evolution/EvolutionSyncSource.cpp

348 lines
13 KiB
C++
Raw Normal View History

redesigned SyncSource base class + API The main motivation for this change is that it allows the implementor of a backend to choose the implementations for the different aspects of a datasource (change tracking, item import/export, logging, ...) independently of each other. For example, change tracking via revision strings can now be combined with exchanging data with the Synthesis engine via a single string (the traditional method in SyncEvolution) and with direct access to the Synthesis field list (now possible for the first time). The new backend API is based on the concept of providing implementations for certain functionality via function objects instead of implementing certain virtual methods. The advantage is that implementors can define their own, custom interfaces and mix and match implementations of the different groups of functionality. Logging (see SyncSourceLogging in a later commit) can be done by wrapping some arbitrary other item import/export function objects (decorator design pattern). The class hierarchy is now this: - SyncSourceBase: interface for common utility code, all other classes are derived from it and thus can use that code - SyncSource: base class which implements SyncSourceBase and hooks a datasource into the SyncEvolution core; its "struct Operations" holds the function objects which can be implemented in different ways - TestingSyncSource: combines some of the following classes into an interface that is expected by the client-test program; backends only have to derive from (and implement this) if they want to use the automated testing - TrackingSyncSource: provides the same functionality as before (change tracking via revision strings, item import/export as string) in a single interface; the description of the pure virtual methods are duplicated so that developers can go through this class and find everything they need to know to implement it The following classes contain the code that was previously found in the EvolutionSyncSource base class. Implementors can derive from them and call the init() methods to inherit and activate the functionality: - SyncSourceSession: binds Synthesis session callbacks to virtual methods beginSync(), endSync() - SyncSourceChanges: implements Synthesis item tracking callbacks with set of LUIDs that the user of the class has to fill - SyncSourceDelete: binds Synthesis delete callback to virtual method - SyncSourceRaw: read and write items in the backends format, used for testing and backup/restore - SyncSourceSerialize: exchanges items with Synthesis engine using a string representation of the data; this is how EvolutionSyncSource has traditionally worked, so much of the same virtual methods are now in this class - SyncSourceRevisions: utility class which does change tracking via some kind of "revision" string which changes each time an item is modified; this code was previously in the TrackingSyncSource
2009-08-25 09:27:46 +02:00
/*
* Copyright (C) 2005-2009 Patrick Ohly <patrick.ohly@gmx.de>
* Copyright (C) 2009 Intel Corporation
*
* This library is free software; you can redistribute it and/or
* modify it under the terms of the GNU Lesser General Public
* License as published by the Free Software Foundation; either
* version 2.1 of the License, or (at your option) version 3.
*
* This library is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
* Lesser General Public License for more details.
*
* You should have received a copy of the GNU Lesser General Public
* License along with this library; if not, write to the Free Software
* Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
* 02110-1301 USA
*/
#include "EvolutionSyncSource.h"
Evolution Address Book: avoid picking CouchDB by default, again (MB #7877) The first attempt at solving this problem was incomplete. In addition to reordering the databases so that CouchDB databases are listed last (previous patch), we also must change the code so that the first database *after* reordering is marked as default *and* that actual syncs use that database. Therefore this patch changes EvolutionContactSource::getDatabases() so that the setting of m_isDefault is done at the end and EvolutionSyncSource::findSource() so that it looks at that result when no DB is selected explicitly.
2010-02-22 16:19:12 +01:00
#include <syncevo/SmartPtr.h>
code restructing: Exception, throwError() Raising exceptions via throwError() looses the original source code location information. Fixing that by explicitly passing that information as additional parameter, created with the preprocessor macro SE_HERE. Several files included the complex SyncContext.h only because needed throwError(). A better place for the revised implementation is the Exception class which used to be in util.h, now Exception.h. Simplifying the include statements exposed indirect include dependencies and removed "using namespace std" from the compilation of some source files which happened to rely on it. We want to get rid of that name space polution, so fix the code instead of adding it back.
2014-04-02 14:57:56 +02:00
#include <syncevo/Exception.h>
EDS: create new databases by cloning the builtin ones (FDO #64176) Instead of hard-coding a specific "Backend Summary Setup" in SyncEvolution, copy the config of the system database. That way special flags (like the desired "Backend Summary Setup" for local address books) can be set on a system-wide basis and without having to modify or configure SyncEvolution. Because EDS has no APIs to clone an ESource or turn a .source file into a new ESource, SyncEvolution has to resort to manipulating and creating the keyfile directly.
2013-05-23 17:38:04 +02:00
#include <syncevo/GLibSupport.h>
PIM: allow removal of data together with database removal (part of FDO #64835) There is a difference in EDS between removing the database definition from the ESourceRegistry (which makes the data unaccessible via EDS) and removing the actual database. EDS itself only removes the definition and leaves the data around to be garbage-collected eventually. This is not what we want for the PIM Manager API; the API makes a stronger guarantee that data is really gone. Fixed by introducing a new mode flag for the deleteDatabase() method and deleting the directory of the source directly in the EDS backend, if requested by the caller. The syncevolution command line tool will use the default mode and thus keep the data around, while the PIM Manager forces the removal of data.
2013-05-24 09:42:13 +02:00
#ifdef USE_EDS_CLIENT
#include <syncevo/GValueSupport.h>
EDS: create new databases by cloning the builtin ones (FDO #64176) Instead of hard-coding a specific "Backend Summary Setup" in SyncEvolution, copy the config of the system database. That way special flags (like the desired "Backend Summary Setup" for local address books) can be set on a system-wide basis and without having to modify or configure SyncEvolution. Because EDS has no APIs to clone an ESource or turn a .source file into a new ESource, SyncEvolution has to resort to manipulating and creating the keyfile directly.
2013-05-23 17:38:04 +02:00
SE_GLIB_TYPE(GKeyFile, g_key_file)
PIM: allow removal of data together with database removal (part of FDO #64835) There is a difference in EDS between removing the database definition from the ESourceRegistry (which makes the data unaccessible via EDS) and removing the actual database. EDS itself only removes the definition and leaves the data around to be garbage-collected eventually. This is not what we want for the PIM Manager API; the API makes a stronger guarantee that data is really gone. Fixed by introducing a new mode flag for the deleteDatabase() method and deleting the directory of the source directly in the EDS backend, if requested by the caller. The syncevolution command line tool will use the default mode and thus keep the data around, while the PIM Manager forces the removal of data.
2013-05-24 09:42:13 +02:00
#endif
redesigned SyncSource base class + API The main motivation for this change is that it allows the implementor of a backend to choose the implementations for the different aspects of a datasource (change tracking, item import/export, logging, ...) independently of each other. For example, change tracking via revision strings can now be combined with exchanging data with the Synthesis engine via a single string (the traditional method in SyncEvolution) and with direct access to the Synthesis field list (now possible for the first time). The new backend API is based on the concept of providing implementations for certain functionality via function objects instead of implementing certain virtual methods. The advantage is that implementors can define their own, custom interfaces and mix and match implementations of the different groups of functionality. Logging (see SyncSourceLogging in a later commit) can be done by wrapping some arbitrary other item import/export function objects (decorator design pattern). The class hierarchy is now this: - SyncSourceBase: interface for common utility code, all other classes are derived from it and thus can use that code - SyncSource: base class which implements SyncSourceBase and hooks a datasource into the SyncEvolution core; its "struct Operations" holds the function objects which can be implemented in different ways - TestingSyncSource: combines some of the following classes into an interface that is expected by the client-test program; backends only have to derive from (and implement this) if they want to use the automated testing - TrackingSyncSource: provides the same functionality as before (change tracking via revision strings, item import/export as string) in a single interface; the description of the pure virtual methods are duplicated so that developers can go through this class and find everything they need to know to implement it The following classes contain the code that was previously found in the EvolutionSyncSource base class. Implementors can derive from them and call the init() methods to inherit and activate the functionality: - SyncSourceSession: binds Synthesis session callbacks to virtual methods beginSync(), endSync() - SyncSourceChanges: implements Synthesis item tracking callbacks with set of LUIDs that the user of the class has to fill - SyncSourceDelete: binds Synthesis delete callback to virtual method - SyncSourceRaw: read and write items in the backends format, used for testing and backup/restore - SyncSourceSerialize: exchanges items with Synthesis engine using a string representation of the data; this is how EvolutionSyncSource has traditionally worked, so much of the same virtual methods are now in this class - SyncSourceRevisions: utility class which does change tracking via some kind of "revision" string which changes each time an item is modified; this code was previously in the TrackingSyncSource
2009-08-25 09:27:46 +02:00
files and classes renamed, include statements cleaned up The intention is to get rid of the historic and inconsistent naming of some classes and their corresponding files: * EvolutionSyncClient = class derived from Funambol's SyncClient, * SyncEvolutionConfig = SyncEvolution's config With the strict 'namespace SyncEvo' and the syncevo/ path prefix for most header files it is no longer necessary to have "SyncEvolution" or "Evolution" in the names. This patch thus renames as follows: EvolutionSyncClient => SyncContext EvolutionSmartPtr => SmartPtr SyncEvolutionCmdline => Cmdline SyncEvolutionConfig => SyncConfig SyncEvolutionUtil => util The former EvolutionSyncClient always had a role that went beyond just running a sync, for example it also provided config access. With the upcoming server support it also won't be just a client. Thus the new name "SyncContext". The 'syncevo/' prefix is used throughout the code now. removed whenever the prefix made it clear that the file belongs to SyncEvolution. This helps finding incorrect include paths. Quotes should be used exclusively for SyncEvolution files which don't have a specific prefix yet (test.h, config.h) to help identifying them.
2009-10-05 14:49:32 +02:00
#include <syncevo/declarations.h>
introduced "namespace SyncEvo" consistently Added syncevo/declarations.h, which has This is now used for all SyncEvolution source files, except for the GTK UI, which is written in plain C. In the library it helps to avoid name clashes. The reason for using defines instead of spelling out "namespace SyncEvo" is twofold: 1. if that should ever become necessary, it is easier to rename the namespace via configure options by changing the define 2. editors don't indent the whole file content
2009-10-02 17:23:53 +02:00
SE_BEGIN_CXX
redesigned SyncSource base class + API The main motivation for this change is that it allows the implementor of a backend to choose the implementations for the different aspects of a datasource (change tracking, item import/export, logging, ...) independently of each other. For example, change tracking via revision strings can now be combined with exchanging data with the Synthesis engine via a single string (the traditional method in SyncEvolution) and with direct access to the Synthesis field list (now possible for the first time). The new backend API is based on the concept of providing implementations for certain functionality via function objects instead of implementing certain virtual methods. The advantage is that implementors can define their own, custom interfaces and mix and match implementations of the different groups of functionality. Logging (see SyncSourceLogging in a later commit) can be done by wrapping some arbitrary other item import/export function objects (decorator design pattern). The class hierarchy is now this: - SyncSourceBase: interface for common utility code, all other classes are derived from it and thus can use that code - SyncSource: base class which implements SyncSourceBase and hooks a datasource into the SyncEvolution core; its "struct Operations" holds the function objects which can be implemented in different ways - TestingSyncSource: combines some of the following classes into an interface that is expected by the client-test program; backends only have to derive from (and implement this) if they want to use the automated testing - TrackingSyncSource: provides the same functionality as before (change tracking via revision strings, item import/export as string) in a single interface; the description of the pure virtual methods are duplicated so that developers can go through this class and find everything they need to know to implement it The following classes contain the code that was previously found in the EvolutionSyncSource base class. Implementors can derive from them and call the init() methods to inherit and activate the functionality: - SyncSourceSession: binds Synthesis session callbacks to virtual methods beginSync(), endSync() - SyncSourceChanges: implements Synthesis item tracking callbacks with set of LUIDs that the user of the class has to fill - SyncSourceDelete: binds Synthesis delete callback to virtual method - SyncSourceRaw: read and write items in the backends format, used for testing and backup/restore - SyncSourceSerialize: exchanges items with Synthesis engine using a string representation of the data; this is how EvolutionSyncSource has traditionally worked, so much of the same virtual methods are now in this class - SyncSourceRevisions: utility class which does change tracking via some kind of "revision" string which changes each time an item is modified; this code was previously in the TrackingSyncSource
2009-08-25 09:27:46 +02:00
#ifdef HAVE_EDS
EDS: added support for EDS 3.5.x When compiled against EDS 3.5.x or later, SyncEvolution now uses the backend code originally written for the EClient API introduced in EDS 3.2. That code was changed so that it works with the new include file rules and ESourceRegistry in EDS 3.5.x. Support for using the EClient API with EDS 3.4 was removed because maintaining three different flavors of the EDS backend code would be too much work and not gain much (just the possibility to test the EDSClient code with 3.4). At the moment, this is a compile time choice made automatically by configure. syncevolution.org binaries are compiled against an older EDS and thus do not work with EDS 3.5.x or later. EDS 3.5.x handles authentication itself, using a standard system prompt if necessary. SyncEvolution can no longer provide the password, and thus the "databaseUser/Password" options have no effect when using EDS 3.5.x. The patch leaves code for older EDS almost completely unchanged and therefore is considered safe for the stable release series leading to 1.3. Using EClient is an all-or-nothing choice now, because the common EvolutionSyncSource needs to be compiled differently. Thanks to the reorganized API, a lot more common code for ECal and EBook sources could be moved into EvolutionSyncSource.
2012-07-24 10:25:20 +02:00
#ifdef USE_EDS_CLIENT
void EvolutionSyncSource::getDatabasesFromRegistry(SyncSource::Databases &result,
const char *extension,
ESource *(*refDef)(ESourceRegistry *))
{
EDS: share ESourceRegistry via libsyncevolution Switch to the new EDSRegistryLoader from libsyncevolution. This will allow sharing the ESourceRegistry with the PIM Manager.
2012-12-03 11:44:01 +01:00
ESourceRegistryCXX registry = EDSRegistryLoader::getESourceRegistry();
EDS: added support for EDS 3.5.x When compiled against EDS 3.5.x or later, SyncEvolution now uses the backend code originally written for the EClient API introduced in EDS 3.2. That code was changed so that it works with the new include file rules and ESourceRegistry in EDS 3.5.x. Support for using the EClient API with EDS 3.4 was removed because maintaining three different flavors of the EDS backend code would be too much work and not gain much (just the possibility to test the EDSClient code with 3.4). At the moment, this is a compile time choice made automatically by configure. syncevolution.org binaries are compiled against an older EDS and thus do not work with EDS 3.5.x or later. EDS 3.5.x handles authentication itself, using a standard system prompt if necessary. SyncEvolution can no longer provide the password, and thus the "databaseUser/Password" options have no effect when using EDS 3.5.x. The patch leaves code for older EDS almost completely unchanged and therefore is considered safe for the stable release series leading to 1.3. Using EClient is an all-or-nothing choice now, because the common EvolutionSyncSource needs to be compiled differently. Thanks to the reorganized API, a lot more common code for ECal and EBook sources could be moved into EvolutionSyncSource.
2012-07-24 10:25:20 +02:00
ESourceListCXX sources(e_source_registry_list_sources(registry, extension));
ESourceCXX def(refDef ? refDef(registry) : NULL,
glib: stricter ref counting Following the boost::instrusive_ptr example and making "add_ref = true" the default in our CXX GLib and GObject wrappers led to some memory leaks because it didn't enforce thinking about whether the plain pointer is already owned by us or not. It is better to use a mandatory enum value, ADD_REF and TRANSFER_REF, and force explicit construction. Doing that revealed that the assignment operator was implemented as constructing a CXX instance with increased ref count and/or that in some places, a real leak was caused by increasing the ref count unnecessarily. Running under valgrind gave a false sense of security. Some of the real leaks only showed up randomly in tests.
2013-05-13 21:33:34 +02:00
TRANSFER_REF);
C++: simpler for loops boost/foreach.hpp is no longer needed, range-based loops work the same. With some helpers, even reverse iteration and boost::make_split_iterator() can be handled the same way. "auto" makes it possible to avoid explicitly spelling out the expected type. Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
2018-01-16 10:58:04 +01:00
for (ESource *source: sources) {
EDS: added support for EDS 3.5.x When compiled against EDS 3.5.x or later, SyncEvolution now uses the backend code originally written for the EClient API introduced in EDS 3.2. That code was changed so that it works with the new include file rules and ESourceRegistry in EDS 3.5.x. Support for using the EClient API with EDS 3.4 was removed because maintaining three different flavors of the EDS backend code would be too much work and not gain much (just the possibility to test the EDSClient code with 3.4). At the moment, this is a compile time choice made automatically by configure. syncevolution.org binaries are compiled against an older EDS and thus do not work with EDS 3.5.x or later. EDS 3.5.x handles authentication itself, using a standard system prompt if necessary. SyncEvolution can no longer provide the password, and thus the "databaseUser/Password" options have no effect when using EDS 3.5.x. The patch leaves code for older EDS almost completely unchanged and therefore is considered safe for the stable release series leading to 1.3. Using EClient is an all-or-nothing choice now, because the common EvolutionSyncSource needs to be compiled differently. Thanks to the reorganized API, a lot more common code for ECal and EBook sources could be moved into EvolutionSyncSource.
2012-07-24 10:25:20 +02:00
result.push_back(Database(e_source_get_display_name(source),
e_source_get_uid(source),
e_source_equal(def, source)));
}
}
static void handleErrorCB(EClient */*client*/, const gchar *error_msg, gpointer user_data)
{
EvolutionSyncSource *that = static_cast<EvolutionSyncSource *>(user_data);
Logging: eliminate _instance from SE_LOG* macros With the _instance parameter always being NULL thanks to the previous patch, it can be removed completely.
2013-04-08 19:17:36 +02:00
SE_LOG_ERROR(that->getDisplayName(), "%s", error_msg);
EDS: added support for EDS 3.5.x When compiled against EDS 3.5.x or later, SyncEvolution now uses the backend code originally written for the EClient API introduced in EDS 3.2. That code was changed so that it works with the new include file rules and ESourceRegistry in EDS 3.5.x. Support for using the EClient API with EDS 3.4 was removed because maintaining three different flavors of the EDS backend code would be too much work and not gain much (just the possibility to test the EDSClient code with 3.4). At the moment, this is a compile time choice made automatically by configure. syncevolution.org binaries are compiled against an older EDS and thus do not work with EDS 3.5.x or later. EDS 3.5.x handles authentication itself, using a standard system prompt if necessary. SyncEvolution can no longer provide the password, and thus the "databaseUser/Password" options have no effect when using EDS 3.5.x. The patch leaves code for older EDS almost completely unchanged and therefore is considered safe for the stable release series leading to 1.3. Using EClient is an all-or-nothing choice now, because the common EvolutionSyncSource needs to be compiled differently. Thanks to the reorganized API, a lot more common code for ECal and EBook sources could be moved into EvolutionSyncSource.
2012-07-24 10:25:20 +02:00
}
EClientCXX EvolutionSyncSource::openESource(const char *extension,
ESource *(*refBuiltin)(ESourceRegistry *),
C++: replace boost::shared_ptr, boost::function, boost::bind We can use std::shared_ptr and std::function instead now. Lambdas are usually a better alternative to boost/std::bind. The downside is the need to explicitly specify parameters completely. When inlining callbacks entirely with lambdas, duplication of that parameter list can be avoided. Whenever possible, use std::make_shared to construct objects that are tracked by std::shared_ptr. Some objects need a std::weak_ptr during object destruction. For that we have to use our own implementation of std::enable_shared_from_this, with a matching creator function. The additional benefit is that we can get rid of explicit static "create" methods by making that create function a friend. Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
2018-01-16 17:17:34 +01:00
const std::function<EClient *(ESource *, GError **gerror)> &newClient)
EDS: added support for EDS 3.5.x When compiled against EDS 3.5.x or later, SyncEvolution now uses the backend code originally written for the EClient API introduced in EDS 3.2. That code was changed so that it works with the new include file rules and ESourceRegistry in EDS 3.5.x. Support for using the EClient API with EDS 3.4 was removed because maintaining three different flavors of the EDS backend code would be too much work and not gain much (just the possibility to test the EDSClient code with 3.4). At the moment, this is a compile time choice made automatically by configure. syncevolution.org binaries are compiled against an older EDS and thus do not work with EDS 3.5.x or later. EDS 3.5.x handles authentication itself, using a standard system prompt if necessary. SyncEvolution can no longer provide the password, and thus the "databaseUser/Password" options have no effect when using EDS 3.5.x. The patch leaves code for older EDS almost completely unchanged and therefore is considered safe for the stable release series leading to 1.3. Using EClient is an all-or-nothing choice now, because the common EvolutionSyncSource needs to be compiled differently. Thanks to the reorganized API, a lot more common code for ECal and EBook sources could be moved into EvolutionSyncSource.
2012-07-24 10:25:20 +02:00
{
EClientCXX client;
GErrorCXX gerror;
EDS: share ESourceRegistry via libsyncevolution Switch to the new EDSRegistryLoader from libsyncevolution. This will allow sharing the ESourceRegistry with the PIM Manager.
2012-12-03 11:44:01 +01:00
ESourceRegistryCXX registry = EDSRegistryLoader::getESourceRegistry();
EDS: added support for EDS 3.5.x When compiled against EDS 3.5.x or later, SyncEvolution now uses the backend code originally written for the EClient API introduced in EDS 3.2. That code was changed so that it works with the new include file rules and ESourceRegistry in EDS 3.5.x. Support for using the EClient API with EDS 3.4 was removed because maintaining three different flavors of the EDS backend code would be too much work and not gain much (just the possibility to test the EDSClient code with 3.4). At the moment, this is a compile time choice made automatically by configure. syncevolution.org binaries are compiled against an older EDS and thus do not work with EDS 3.5.x or later. EDS 3.5.x handles authentication itself, using a standard system prompt if necessary. SyncEvolution can no longer provide the password, and thus the "databaseUser/Password" options have no effect when using EDS 3.5.x. The patch leaves code for older EDS almost completely unchanged and therefore is considered safe for the stable release series leading to 1.3. Using EClient is an all-or-nothing choice now, because the common EvolutionSyncSource needs to be compiled differently. Thanks to the reorganized API, a lot more common code for ECal and EBook sources could be moved into EvolutionSyncSource.
2012-07-24 10:25:20 +02:00
ESourceListCXX sources(e_source_registry_list_sources(registry, extension));
string id = getDatabaseID();
ESource *source = findSource(sources, id);
if (!source) {
if (refBuiltin && (id.empty() || id == "<<system>>")) {
glib: stricter ref counting Following the boost::instrusive_ptr example and making "add_ref = true" the default in our CXX GLib and GObject wrappers led to some memory leaks because it didn't enforce thinking about whether the plain pointer is already owned by us or not. It is better to use a mandatory enum value, ADD_REF and TRANSFER_REF, and force explicit construction. Doing that revealed that the assignment operator was implemented as constructing a CXX instance with increased ref count and/or that in some places, a real leak was caused by increasing the ref count unnecessarily. Running under valgrind gave a false sense of security. Some of the real leaks only showed up randomly in tests.
2013-05-13 21:33:34 +02:00
ESourceCXX builtin(refBuiltin(registry), TRANSFER_REF);
EDS: added support for EDS 3.5.x When compiled against EDS 3.5.x or later, SyncEvolution now uses the backend code originally written for the EClient API introduced in EDS 3.2. That code was changed so that it works with the new include file rules and ESourceRegistry in EDS 3.5.x. Support for using the EClient API with EDS 3.4 was removed because maintaining three different flavors of the EDS backend code would be too much work and not gain much (just the possibility to test the EDSClient code with 3.4). At the moment, this is a compile time choice made automatically by configure. syncevolution.org binaries are compiled against an older EDS and thus do not work with EDS 3.5.x or later. EDS 3.5.x handles authentication itself, using a standard system prompt if necessary. SyncEvolution can no longer provide the password, and thus the "databaseUser/Password" options have no effect when using EDS 3.5.x. The patch leaves code for older EDS almost completely unchanged and therefore is considered safe for the stable release series leading to 1.3. Using EClient is an all-or-nothing choice now, because the common EvolutionSyncSource needs to be compiled differently. Thanks to the reorganized API, a lot more common code for ECal and EBook sources could be moved into EvolutionSyncSource.
2012-07-24 10:25:20 +02:00
client = EClientCXX::steal(newClient(builtin, gerror));
// } else if (!id.compare(0, 7, "file://")) {
// TODO: create source
// m_calendar = ECalClientCXX::steal(e_cal_client_new_from_uri(id.c_str(), sourceType(), gerror));
} else {
code restructing: Exception, throwError() Raising exceptions via throwError() looses the original source code location information. Fixing that by explicitly passing that information as additional parameter, created with the preprocessor macro SE_HERE. Several files included the complex SyncContext.h only because needed throwError(). A better place for the revised implementation is the Exception class which used to be in util.h, now Exception.h. Simplifying the include statements exposed indirect include dependencies and removed "using namespace std" from the compilation of some source files which happened to rely on it. We want to get rid of that name space polution, so fix the code instead of adding it back.
2014-04-02 14:57:56 +02:00
throwError(SE_HERE, string("database not found: '") + id + "'");
EDS: added support for EDS 3.5.x When compiled against EDS 3.5.x or later, SyncEvolution now uses the backend code originally written for the EClient API introduced in EDS 3.2. That code was changed so that it works with the new include file rules and ESourceRegistry in EDS 3.5.x. Support for using the EClient API with EDS 3.4 was removed because maintaining three different flavors of the EDS backend code would be too much work and not gain much (just the possibility to test the EDSClient code with 3.4). At the moment, this is a compile time choice made automatically by configure. syncevolution.org binaries are compiled against an older EDS and thus do not work with EDS 3.5.x or later. EDS 3.5.x handles authentication itself, using a standard system prompt if necessary. SyncEvolution can no longer provide the password, and thus the "databaseUser/Password" options have no effect when using EDS 3.5.x. The patch leaves code for older EDS almost completely unchanged and therefore is considered safe for the stable release series leading to 1.3. Using EClient is an all-or-nothing choice now, because the common EvolutionSyncSource needs to be compiled differently. Thanks to the reorganized API, a lot more common code for ECal and EBook sources could be moved into EvolutionSyncSource.
2012-07-24 10:25:20 +02:00
}
} else {
client = EClientCXX::steal(newClient(source, gerror));
}
if (!client) {
code restructing: Exception, throwError() Raising exceptions via throwError() looses the original source code location information. Fixing that by explicitly passing that information as additional parameter, created with the preprocessor macro SE_HERE. Several files included the complex SyncContext.h only because needed throwError(). A better place for the revised implementation is the Exception class which used to be in util.h, now Exception.h. Simplifying the include statements exposed indirect include dependencies and removed "using namespace std" from the compilation of some source files which happened to rely on it. We want to get rid of that name space polution, so fix the code instead of adding it back.
2014-04-02 14:57:56 +02:00
throwError(SE_HERE, "accessing database", gerror);
EDS: added support for EDS 3.5.x When compiled against EDS 3.5.x or later, SyncEvolution now uses the backend code originally written for the EClient API introduced in EDS 3.2. That code was changed so that it works with the new include file rules and ESourceRegistry in EDS 3.5.x. Support for using the EClient API with EDS 3.4 was removed because maintaining three different flavors of the EDS backend code would be too much work and not gain much (just the possibility to test the EDSClient code with 3.4). At the moment, this is a compile time choice made automatically by configure. syncevolution.org binaries are compiled against an older EDS and thus do not work with EDS 3.5.x or later. EDS 3.5.x handles authentication itself, using a standard system prompt if necessary. SyncEvolution can no longer provide the password, and thus the "databaseUser/Password" options have no effect when using EDS 3.5.x. The patch leaves code for older EDS almost completely unchanged and therefore is considered safe for the stable release series leading to 1.3. Using EClient is an all-or-nothing choice now, because the common EvolutionSyncSource needs to be compiled differently. Thanks to the reorganized API, a lot more common code for ECal and EBook sources could be moved into EvolutionSyncSource.
2012-07-24 10:25:20 +02:00
}
// Listen for errors
g_signal_connect (client, "backend-error", G_CALLBACK(handleErrorCB), this);
g_signal_connect_after(client,
"backend-died",
code restructing: Exception, throwError() Raising exceptions via throwError() looses the original source code location information. Fixing that by explicitly passing that information as additional parameter, created with the preprocessor macro SE_HERE. Several files included the complex SyncContext.h only because needed throwError(). A better place for the revised implementation is the Exception class which used to be in util.h, now Exception.h. Simplifying the include statements exposed indirect include dependencies and removed "using namespace std" from the compilation of some source files which happened to rely on it. We want to get rid of that name space polution, so fix the code instead of adding it back.
2014-04-02 14:57:56 +02:00
G_CALLBACK(Exception::fatalError),
EDS: added support for EDS 3.5.x When compiled against EDS 3.5.x or later, SyncEvolution now uses the backend code originally written for the EClient API introduced in EDS 3.2. That code was changed so that it works with the new include file rules and ESourceRegistry in EDS 3.5.x. Support for using the EClient API with EDS 3.4 was removed because maintaining three different flavors of the EDS backend code would be too much work and not gain much (just the possibility to test the EDSClient code with 3.4). At the moment, this is a compile time choice made automatically by configure. syncevolution.org binaries are compiled against an older EDS and thus do not work with EDS 3.5.x or later. EDS 3.5.x handles authentication itself, using a standard system prompt if necessary. SyncEvolution can no longer provide the password, and thus the "databaseUser/Password" options have no effect when using EDS 3.5.x. The patch leaves code for older EDS almost completely unchanged and therefore is considered safe for the stable release series leading to 1.3. Using EClient is an all-or-nothing choice now, because the common EvolutionSyncSource needs to be compiled differently. Thanks to the reorganized API, a lot more common code for ECal and EBook sources could be moved into EvolutionSyncSource.
2012-07-24 10:25:20 +02:00
(void *)"Evolution Data Server has died unexpectedly.");
EDS: more generic open retry handling Recent EDS started to exhibit race conditions when opening a database (for example, https://bugzilla.gnome.org/show_bug.cgi?id=791306). Opening was already tried again for a certain known error in some old EDS version. Now it is tried five times with a delay of one second for all errors. The advantage is that this does not depend on accurately detecting the race condition error. Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
2018-01-01 15:05:12 +01:00
int retries = 0;
EDS Client: handle "busy" error In EDS 3.6.4, opening fails a lot more often with E_CLIENT_ERROR_BUSY. We must retry until we succeed. Seen in particular with testpim.py testFilterStartup. Clients are expected to try the open call again. EDS >= 3.8 does that automatically.
2013-04-02 16:36:21 +02:00
while (true) {
// Always allow EDS to create the database. "only-if-exists =
// true" does not make sense.
if (!e_client_open_sync(client, false, NULL, gerror)) {
EDS: more generic open retry handling Recent EDS started to exhibit race conditions when opening a database (for example, https://bugzilla.gnome.org/show_bug.cgi?id=791306). Opening was already tried again for a certain known error in some old EDS version. Now it is tried five times with a delay of one second for all errors. The advantage is that this does not depend on accurately detecting the race condition error. Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
2018-01-01 15:05:12 +01:00
if (retries < 5) {
// EDS 3.18 and 3.26 have various race conditions during startup.
// Try a few times.
// https://bugzilla.gnome.org/show_bug.cgi?id=791306
SE_LOG_DEBUG(NULL, "Opening EDS source: ignoring error, trying again: %s", gerror->message);
EDS Client: handle "busy" error In EDS 3.6.4, opening fails a lot more often with E_CLIENT_ERROR_BUSY. We must retry until we succeed. Seen in particular with testpim.py testFilterStartup. Clients are expected to try the open call again. EDS >= 3.8 does that automatically.
2013-04-02 16:36:21 +02:00
gerror.clear();
sleep(1);
EDS: more generic open retry handling Recent EDS started to exhibit race conditions when opening a database (for example, https://bugzilla.gnome.org/show_bug.cgi?id=791306). Opening was already tried again for a certain known error in some old EDS version. Now it is tried five times with a delay of one second for all errors. The advantage is that this does not depend on accurately detecting the race condition error. Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
2018-01-01 15:05:12 +01:00
retries++;
EDS Client: handle "busy" error In EDS 3.6.4, opening fails a lot more often with E_CLIENT_ERROR_BUSY. We must retry until we succeed. Seen in particular with testpim.py testFilterStartup. Clients are expected to try the open call again. EDS >= 3.8 does that automatically.
2013-04-02 16:36:21 +02:00
} else {
code restructing: Exception, throwError() Raising exceptions via throwError() looses the original source code location information. Fixing that by explicitly passing that information as additional parameter, created with the preprocessor macro SE_HERE. Several files included the complex SyncContext.h only because needed throwError(). A better place for the revised implementation is the Exception class which used to be in util.h, now Exception.h. Simplifying the include statements exposed indirect include dependencies and removed "using namespace std" from the compilation of some source files which happened to rely on it. We want to get rid of that name space polution, so fix the code instead of adding it back.
2014-04-02 14:57:56 +02:00
throwError(SE_HERE, "opening database", gerror);
EDS: added support for EDS 3.5.x When compiled against EDS 3.5.x or later, SyncEvolution now uses the backend code originally written for the EClient API introduced in EDS 3.2. That code was changed so that it works with the new include file rules and ESourceRegistry in EDS 3.5.x. Support for using the EClient API with EDS 3.4 was removed because maintaining three different flavors of the EDS backend code would be too much work and not gain much (just the possibility to test the EDSClient code with 3.4). At the moment, this is a compile time choice made automatically by configure. syncevolution.org binaries are compiled against an older EDS and thus do not work with EDS 3.5.x or later. EDS 3.5.x handles authentication itself, using a standard system prompt if necessary. SyncEvolution can no longer provide the password, and thus the "databaseUser/Password" options have no effect when using EDS 3.5.x. The patch leaves code for older EDS almost completely unchanged and therefore is considered safe for the stable release series leading to 1.3. Using EClient is an all-or-nothing choice now, because the common EvolutionSyncSource needs to be compiled differently. Thanks to the reorganized API, a lot more common code for ECal and EBook sources could be moved into EvolutionSyncSource.
2012-07-24 10:25:20 +02:00
}
} else {
EDS Client: handle "busy" error In EDS 3.6.4, opening fails a lot more often with E_CLIENT_ERROR_BUSY. We must retry until we succeed. Seen in particular with testpim.py testFilterStartup. Clients are expected to try the open call again. EDS >= 3.8 does that automatically.
2013-04-02 16:36:21 +02:00
// Success!
break;
EDS: added support for EDS 3.5.x When compiled against EDS 3.5.x or later, SyncEvolution now uses the backend code originally written for the EClient API introduced in EDS 3.2. That code was changed so that it works with the new include file rules and ESourceRegistry in EDS 3.5.x. Support for using the EClient API with EDS 3.4 was removed because maintaining three different flavors of the EDS backend code would be too much work and not gain much (just the possibility to test the EDSClient code with 3.4). At the moment, this is a compile time choice made automatically by configure. syncevolution.org binaries are compiled against an older EDS and thus do not work with EDS 3.5.x or later. EDS 3.5.x handles authentication itself, using a standard system prompt if necessary. SyncEvolution can no longer provide the password, and thus the "databaseUser/Password" options have no effect when using EDS 3.5.x. The patch leaves code for older EDS almost completely unchanged and therefore is considered safe for the stable release series leading to 1.3. Using EClient is an all-or-nothing choice now, because the common EvolutionSyncSource needs to be compiled differently. Thanks to the reorganized API, a lot more common code for ECal and EBook sources could be moved into EvolutionSyncSource.
2012-07-24 10:25:20 +02:00
}
}
EDS Client: implement creating and deleting databases Depends on the EDS 3.6 ESourceRegistry API. Needs the very latest EDS with the following commit. There's no configure check yet because EDS 3.6 is not released yet. commit 6df76009318eac9dbe3dd49165394d389102764e Author: Matthew Barnes <mbarnes@redhat.com> Date: Tue Sep 11 22:56:08 2012 -0400 Bug 683785 - Add e_source_new_with_uid() Variation of e_source_new() which allows a predetermined UID to be specified for a scratch source. This changes the "uid" property from read-only to read/write + construct-only, and eliminates the need for EServerSideSource to override the property.
2012-09-13 17:57:28 +02:00
// record result for SyncSource::getDatabase()
source = e_client_get_source(client);
if (source) {
Database database(e_source_get_display_name(source),
e_source_get_uid(source));
setDatabase(database);
}
EDS: added support for EDS 3.5.x When compiled against EDS 3.5.x or later, SyncEvolution now uses the backend code originally written for the EClient API introduced in EDS 3.2. That code was changed so that it works with the new include file rules and ESourceRegistry in EDS 3.5.x. Support for using the EClient API with EDS 3.4 was removed because maintaining three different flavors of the EDS backend code would be too much work and not gain much (just the possibility to test the EDSClient code with 3.4). At the moment, this is a compile time choice made automatically by configure. syncevolution.org binaries are compiled against an older EDS and thus do not work with EDS 3.5.x or later. EDS 3.5.x handles authentication itself, using a standard system prompt if necessary. SyncEvolution can no longer provide the password, and thus the "databaseUser/Password" options have no effect when using EDS 3.5.x. The patch leaves code for older EDS almost completely unchanged and therefore is considered safe for the stable release series leading to 1.3. Using EClient is an all-or-nothing choice now, because the common EvolutionSyncSource needs to be compiled differently. Thanks to the reorganized API, a lot more common code for ECal and EBook sources could be moved into EvolutionSyncSource.
2012-07-24 10:25:20 +02:00
return client;
}
EDS Client: implement creating and deleting databases Depends on the EDS 3.6 ESourceRegistry API. Needs the very latest EDS with the following commit. There's no configure check yet because EDS 3.6 is not released yet. commit 6df76009318eac9dbe3dd49165394d389102764e Author: Matthew Barnes <mbarnes@redhat.com> Date: Tue Sep 11 22:56:08 2012 -0400 Bug 683785 - Add e_source_new_with_uid() Variation of e_source_new() which allows a predetermined UID to be specified for a scratch source. This changes the "uid" property from read-only to read/write + construct-only, and eliminates the need for EServerSideSource to override the property.
2012-09-13 17:57:28 +02:00
SyncSource::Database EvolutionSyncSource::createDatabase(const Database &database)
{
EDS: create new databases by cloning the builtin ones (FDO #64176) Instead of hard-coding a specific "Backend Summary Setup" in SyncEvolution, copy the config of the system database. That way special flags (like the desired "Backend Summary Setup" for local address books) can be set on a system-wide basis and without having to modify or configure SyncEvolution. Because EDS has no APIs to clone an ESource or turn a .source file into a new ESource, SyncEvolution has to resort to manipulating and creating the keyfile directly.
2013-05-23 17:38:04 +02:00
// We'll need this later. Create it before doing any real work.
ESourceRegistryCXX registry = EDSRegistryLoader::getESourceRegistry();
// Clone the system DB. This allows the distro to change the
// configuration (backend, extensions (= in particular
// the contacts DB summary fields)) without having to
// modify SyncEvolution.
ESourceCXX systemSource = refSystemDB();
gsize len;
PlainGStr ini(e_source_to_string(systemSource, &len));
// Modify the entries in the key file directly. We can't
// instantiate an ESource (no API for it), copying the values from
// the key file into a fresh ESource is difficult (would have to
// reimplement EDS internal encoding/decoding), and copying from
// systemSource is hard (don't know which extensions it has,
// cannot instantiate extensions of unknown types, because
// e_source_get_extension() only works for types that were
// created).
static const char *mainSection = "Data Source";
GKeyFileCXX keyfile(g_key_file_new(), TRANSFER_REF);
EDS Client: implement creating and deleting databases Depends on the EDS 3.6 ESourceRegistry API. Needs the very latest EDS with the following commit. There's no configure check yet because EDS 3.6 is not released yet. commit 6df76009318eac9dbe3dd49165394d389102764e Author: Matthew Barnes <mbarnes@redhat.com> Date: Tue Sep 11 22:56:08 2012 -0400 Bug 683785 - Add e_source_new_with_uid() Variation of e_source_new() which allows a predetermined UID to be specified for a scratch source. This changes the "uid" property from read-only to read/write + construct-only, and eliminates the need for EServerSideSource to override the property.
2012-09-13 17:57:28 +02:00
GErrorCXX gerror;
EDS: create new databases by cloning the builtin ones (FDO #64176) Instead of hard-coding a specific "Backend Summary Setup" in SyncEvolution, copy the config of the system database. That way special flags (like the desired "Backend Summary Setup" for local address books) can be set on a system-wide basis and without having to modify or configure SyncEvolution. Because EDS has no APIs to clone an ESource or turn a .source file into a new ESource, SyncEvolution has to resort to manipulating and creating the keyfile directly.
2013-05-23 17:38:04 +02:00
if (!g_key_file_load_from_data(keyfile, ini, len, G_KEY_FILE_NONE, gerror)) {
code restructing: Exception, throwError() Raising exceptions via throwError() looses the original source code location information. Fixing that by explicitly passing that information as additional parameter, created with the preprocessor macro SE_HERE. Several files included the complex SyncContext.h only because needed throwError(). A better place for the revised implementation is the Exception class which used to be in util.h, now Exception.h. Simplifying the include statements exposed indirect include dependencies and removed "using namespace std" from the compilation of some source files which happened to rely on it. We want to get rid of that name space polution, so fix the code instead of adding it back.
2014-04-02 14:57:56 +02:00
gerror.throwError(SE_HERE, "parsing ESource .ini data");
EDS Client: implement creating and deleting databases Depends on the EDS 3.6 ESourceRegistry API. Needs the very latest EDS with the following commit. There's no configure check yet because EDS 3.6 is not released yet. commit 6df76009318eac9dbe3dd49165394d389102764e Author: Matthew Barnes <mbarnes@redhat.com> Date: Tue Sep 11 22:56:08 2012 -0400 Bug 683785 - Add e_source_new_with_uid() Variation of e_source_new() which allows a predetermined UID to be specified for a scratch source. This changes the "uid" property from read-only to read/write + construct-only, and eliminates the need for EServerSideSource to override the property.
2012-09-13 17:57:28 +02:00
}
EDS: fix cloning of system source The localized DisplayName strings must be removed explicitly. To find them, list all properties in the main section and then remove if the prefix matches.
2013-06-28 11:05:13 +02:00
PlainGStrArray keys(g_key_file_get_keys(keyfile, mainSection, NULL, gerror));
if (!keys) {
code restructing: Exception, throwError() Raising exceptions via throwError() looses the original source code location information. Fixing that by explicitly passing that information as additional parameter, created with the preprocessor macro SE_HERE. Several files included the complex SyncContext.h only because needed throwError(). A better place for the revised implementation is the Exception class which used to be in util.h, now Exception.h. Simplifying the include statements exposed indirect include dependencies and removed "using namespace std" from the compilation of some source files which happened to rely on it. We want to get rid of that name space polution, so fix the code instead of adding it back.
2014-04-02 14:57:56 +02:00
gerror.throwError(SE_HERE, "listing keys in main section");
EDS: fix cloning of system source The localized DisplayName strings must be removed explicitly. To find them, list all properties in the main section and then remove if the prefix matches.
2013-06-28 11:05:13 +02:00
}
for (int i = 0; keys.at(i); i++) {
EDS: fix compile problem with boost and EDS > 3.36 This fixes the following problem, seen with Boost 1.53.0 on altlinux when compiling for EDS >= 3.6: /usr/include/boost/smart_ptr/shared_ptr.hpp: In instantiation of 'typename boost::detail::sp_array_access<T>::type boost::shared_ptr<T>::operator[](std::ptrdiff_t) const [with T = char*; typename boost::detail::sp_array_access<T>::type = void; std::ptrdiff_t = long int]': src/backends/evolution/EvolutionSyncSource.cpp:163:38: required from here /usr/include/boost/smart_ptr/shared_ptr.hpp:663:22: error: return-statement with a value, in function returning 'void' [-fpermissive] make[2]: *** [src/backends/evolution/src_backends_evolution_syncecal_la-EvolutionSyncSource.lo] The "void" type above is wrong, so it looks like a missing type trait for the pointer type used in the smart_ptr. PlainGStrArray already had an at() method to work around such issues, so use it. Not sure why this one usage of [] slipped through.
2013-10-18 09:50:18 +02:00
if (boost::starts_with(keys.at(i), "DisplayName[")) {
EDS: fix cloning of system source The localized DisplayName strings must be removed explicitly. To find them, list all properties in the main section and then remove if the prefix matches.
2013-06-28 11:05:13 +02:00
if (!g_key_file_remove_key(keyfile, mainSection, keys.at(i), gerror)) {
code restructing: Exception, throwError() Raising exceptions via throwError() looses the original source code location information. Fixing that by explicitly passing that information as additional parameter, created with the preprocessor macro SE_HERE. Several files included the complex SyncContext.h only because needed throwError(). A better place for the revised implementation is the Exception class which used to be in util.h, now Exception.h. Simplifying the include statements exposed indirect include dependencies and removed "using namespace std" from the compilation of some source files which happened to rely on it. We want to get rid of that name space polution, so fix the code instead of adding it back.
2014-04-02 14:57:56 +02:00
gerror.throwError(SE_HERE, "remove key");
EDS: fix cloning of system source The localized DisplayName strings must be removed explicitly. To find them, list all properties in the main section and then remove if the prefix matches.
2013-06-28 11:05:13 +02:00
}
}
}
EDS: create new databases by cloning the builtin ones (FDO #64176) Instead of hard-coding a specific "Backend Summary Setup" in SyncEvolution, copy the config of the system database. That way special flags (like the desired "Backend Summary Setup" for local address books) can be set on a system-wide basis and without having to modify or configure SyncEvolution. Because EDS has no APIs to clone an ESource or turn a .source file into a new ESource, SyncEvolution has to resort to manipulating and creating the keyfile directly.
2013-05-23 17:38:04 +02:00
g_key_file_set_string(keyfile, mainSection, "DisplayName", database.m_name.c_str());
g_key_file_set_boolean(keyfile, mainSection, "Enabled", true);
ini = g_key_file_to_data(keyfile, &len, NULL);
const char *configDir = g_get_user_config_dir();
int fd;
std::string filename;
std::string uid;
// Create sources dir. It might have been removed (for example, while
// testing) without having been recreated by evolution-source-registry.
std::string sourceDir = StringPrintf("%s/evolution/sources",
configDir);
mkdir_p(sourceDir);
// Create unique ID if necessary.
while (true) {
uid = database.m_uri.empty() ?
UUID() :
database.m_uri;
filename = StringPrintf("%s/%s.source", sourceDir.c_str(), uid.c_str());
fd = ::open(filename.c_str(),
O_WRONLY|O_CREAT|O_EXCL,
S_IRUSR|S_IWUSR);
if (fd >= 0) {
break;
}
if (errno == EEXIST) {
if (!database.m_uri.empty()) {
SE_THROW(StringPrintf("ESource UUID %s already in use", database.m_uri.c_str()));
} else {
// try again with new random UUID
}
} else {
SE_THROW(StringPrintf("creating %s failed: %s", filename.c_str(), strerror(errno)));
}
}
ssize_t written = write(fd, ini.get(), len);
int res = ::close(fd);
PIM: allow removal of data together with database removal (part of FDO #64835) There is a difference in EDS between removing the database definition from the ESourceRegistry (which makes the data unaccessible via EDS) and removing the actual database. EDS itself only removes the definition and leaves the data around to be garbage-collected eventually. This is not what we want for the PIM Manager API; the API makes a stronger guarantee that data is really gone. Fixed by introducing a new mode flag for the deleteDatabase() method and deleting the directory of the source directly in the EDS backend, if requested by the caller. The syncevolution command line tool will use the default mode and thus keep the data around, while the PIM Manager forces the removal of data.
2013-05-24 09:42:13 +02:00
if (written != (ssize_t)len || res) {
EDS: create new databases by cloning the builtin ones (FDO #64176) Instead of hard-coding a specific "Backend Summary Setup" in SyncEvolution, copy the config of the system database. That way special flags (like the desired "Backend Summary Setup" for local address books) can be set on a system-wide basis and without having to modify or configure SyncEvolution. Because EDS has no APIs to clone an ESource or turn a .source file into a new ESource, SyncEvolution has to resort to manipulating and creating the keyfile directly.
2013-05-23 17:38:04 +02:00
SE_THROW(StringPrintf("writing to %s failed: %s", filename.c_str(), strerror(errno)));
EDS + PIM: create phone number summary in contacts DB (part of FDO #59571) A quick-and-dirty solution for enabling phone number summaries when creating contact databases in the PIM Manager: let the EDS backend recognize the special UIDs used by the PIM Manager and then hard-code the minimal set of summary fields and indexed fields which allow executing the E_CONTACT_TEL, E_BOOK_QUERY_EQUALS_NATIONAL_PHONE_NUMBER query quickly. A proper solution would use a new EDS function for parsing ESource defaults from a string and then providing these defaults to the backend from the PIM Manager. Also note that configuring the EDS system address book must be covered elsewhere, because it wouldn't be correct for SyncEvolution as only one of many clients to change the configuration of that. To enable the special support, add the following section to share/evolution-data-server-3.6/rw-sources/system-address-book.source: [Backend Summary Setup] SummaryFields=phone IndexedFields=phone,phone This patch adds new function calls to code shared by syncecal and syncebook, so we have to add libebook-contacts to both to avoid link errors.
2013-02-28 16:39:24 +01:00
}
EDS: create new databases by cloning the builtin ones (FDO #64176) Instead of hard-coding a specific "Backend Summary Setup" in SyncEvolution, copy the config of the system database. That way special flags (like the desired "Backend Summary Setup" for local address books) can be set on a system-wide basis and without having to modify or configure SyncEvolution. Because EDS has no APIs to clone an ESource or turn a .source file into a new ESource, SyncEvolution has to resort to manipulating and creating the keyfile directly.
2013-05-23 17:38:04 +02:00
// We need to wait until ESourceRegistry notices the new file.
SE_LOG_DEBUG(getDisplayName(), "waiting for ESourceRegistry to notice new ESource %s", uid.c_str());
while (!ESourceCXX(e_source_registry_ref_source(registry, uid.c_str()), TRANSFER_REF)) {
// This will block forever if called from the non-main-thread.
// Don't do that...
g_main_context_iteration(NULL, true);
EDS Client: implement creating and deleting databases Depends on the EDS 3.6 ESourceRegistry API. Needs the very latest EDS with the following commit. There's no configure check yet because EDS 3.6 is not released yet. commit 6df76009318eac9dbe3dd49165394d389102764e Author: Matthew Barnes <mbarnes@redhat.com> Date: Tue Sep 11 22:56:08 2012 -0400 Bug 683785 - Add e_source_new_with_uid() Variation of e_source_new() which allows a predetermined UID to be specified for a scratch source. This changes the "uid" property from read-only to read/write + construct-only, and eliminates the need for EServerSideSource to override the property.
2012-09-13 17:57:28 +02:00
}
EDS: create new databases by cloning the builtin ones (FDO #64176) Instead of hard-coding a specific "Backend Summary Setup" in SyncEvolution, copy the config of the system database. That way special flags (like the desired "Backend Summary Setup" for local address books) can be set on a system-wide basis and without having to modify or configure SyncEvolution. Because EDS has no APIs to clone an ESource or turn a .source file into a new ESource, SyncEvolution has to resort to manipulating and creating the keyfile directly.
2013-05-23 17:38:04 +02:00
SE_LOG_DEBUG(getDisplayName(), "ESourceRegistry has new ESource %s", uid.c_str());
// Try triggering that by attempting to create an ESource with the same
// UUID. Does not work! evolution-source-registry simply overwrites the
// file that we created earlier.
// ESourceCXX source(e_source_new_with_uid(uid.c_str(),
// NULL, gerror),
// TRANSFER_REF);
// e_source_set_display_name(source, "syncevolution-fake");
// e_source_set_parent(source, "local-stub");
// ESourceListCXX sources;
// sources.push_back(source.ref()); // ESourceListCXX unrefs sources it points to
// if (!e_source_registry_create_sources_sync(registry,
// sources,
// NULL,
// gerror)) {
code restructing: Exception, throwError() Raising exceptions via throwError() looses the original source code location information. Fixing that by explicitly passing that information as additional parameter, created with the preprocessor macro SE_HERE. Several files included the complex SyncContext.h only because needed throwError(). A better place for the revised implementation is the Exception class which used to be in util.h, now Exception.h. Simplifying the include statements exposed indirect include dependencies and removed "using namespace std" from the compilation of some source files which happened to rely on it. We want to get rid of that name space polution, so fix the code instead of adding it back.
2014-04-02 14:57:56 +02:00
// gerror.throwError(SE_HERE, StringPrintf("creating EDS database of type %s with name '%s'%s%s",
EDS: create new databases by cloning the builtin ones (FDO #64176) Instead of hard-coding a specific "Backend Summary Setup" in SyncEvolution, copy the config of the system database. That way special flags (like the desired "Backend Summary Setup" for local address books) can be set on a system-wide basis and without having to modify or configure SyncEvolution. Because EDS has no APIs to clone an ESource or turn a .source file into a new ESource, SyncEvolution has to resort to manipulating and creating the keyfile directly.
2013-05-23 17:38:04 +02:00
// sourceExtension(),
// database.m_name.c_str(),
// database.m_uri.empty() ? "" : " and URI ",
// database.m_uri.c_str()));
// } else {
// SE_THROW("creating syncevolution-fake ESource succeeded although it should have failed");
// }
return Database(database.m_name, uid);
EDS Client: implement creating and deleting databases Depends on the EDS 3.6 ESourceRegistry API. Needs the very latest EDS with the following commit. There's no configure check yet because EDS 3.6 is not released yet. commit 6df76009318eac9dbe3dd49165394d389102764e Author: Matthew Barnes <mbarnes@redhat.com> Date: Tue Sep 11 22:56:08 2012 -0400 Bug 683785 - Add e_source_new_with_uid() Variation of e_source_new() which allows a predetermined UID to be specified for a scratch source. This changes the "uid" property from read-only to read/write + construct-only, and eliminates the need for EServerSideSource to override the property.
2012-09-13 17:57:28 +02:00
}
PIM: allow removal of data together with database removal (part of FDO #64835) There is a difference in EDS between removing the database definition from the ESourceRegistry (which makes the data unaccessible via EDS) and removing the actual database. EDS itself only removes the definition and leaves the data around to be garbage-collected eventually. This is not what we want for the PIM Manager API; the API makes a stronger guarantee that data is really gone. Fixed by introducing a new mode flag for the deleteDatabase() method and deleting the directory of the source directly in the EDS backend, if requested by the caller. The syncevolution command line tool will use the default mode and thus keep the data around, while the PIM Manager forces the removal of data.
2013-05-24 09:42:13 +02:00
void EvolutionSyncSource::deleteDatabase(const std::string &uri, RemoveData removeData)
EDS Client: implement creating and deleting databases Depends on the EDS 3.6 ESourceRegistry API. Needs the very latest EDS with the following commit. There's no configure check yet because EDS 3.6 is not released yet. commit 6df76009318eac9dbe3dd49165394d389102764e Author: Matthew Barnes <mbarnes@redhat.com> Date: Tue Sep 11 22:56:08 2012 -0400 Bug 683785 - Add e_source_new_with_uid() Variation of e_source_new() which allows a predetermined UID to be specified for a scratch source. This changes the "uid" property from read-only to read/write + construct-only, and eliminates the need for EServerSideSource to override the property.
2012-09-13 17:57:28 +02:00
{
EDS: share ESourceRegistry via libsyncevolution Switch to the new EDSRegistryLoader from libsyncevolution. This will allow sharing the ESourceRegistry with the PIM Manager.
2012-12-03 11:44:01 +01:00
ESourceRegistryCXX registry = EDSRegistryLoader::getESourceRegistry();
glib: stricter ref counting Following the boost::instrusive_ptr example and making "add_ref = true" the default in our CXX GLib and GObject wrappers led to some memory leaks because it didn't enforce thinking about whether the plain pointer is already owned by us or not. It is better to use a mandatory enum value, ADD_REF and TRANSFER_REF, and force explicit construction. Doing that revealed that the assignment operator was implemented as constructing a CXX instance with increased ref count and/or that in some places, a real leak was caused by increasing the ref count unnecessarily. Running under valgrind gave a false sense of security. Some of the real leaks only showed up randomly in tests.
2013-05-13 21:33:34 +02:00
ESourceCXX source(e_source_registry_ref_source(registry, uri.c_str()), TRANSFER_REF);
EDS Client: implement creating and deleting databases Depends on the EDS 3.6 ESourceRegistry API. Needs the very latest EDS with the following commit. There's no configure check yet because EDS 3.6 is not released yet. commit 6df76009318eac9dbe3dd49165394d389102764e Author: Matthew Barnes <mbarnes@redhat.com> Date: Tue Sep 11 22:56:08 2012 -0400 Bug 683785 - Add e_source_new_with_uid() Variation of e_source_new() which allows a predetermined UID to be specified for a scratch source. This changes the "uid" property from read-only to read/write + construct-only, and eliminates the need for EServerSideSource to override the property.
2012-09-13 17:57:28 +02:00
if (!source) {
code restructing: Exception, throwError() Raising exceptions via throwError() looses the original source code location information. Fixing that by explicitly passing that information as additional parameter, created with the preprocessor macro SE_HERE. Several files included the complex SyncContext.h only because needed throwError(). A better place for the revised implementation is the Exception class which used to be in util.h, now Exception.h. Simplifying the include statements exposed indirect include dependencies and removed "using namespace std" from the compilation of some source files which happened to rely on it. We want to get rid of that name space polution, so fix the code instead of adding it back.
2014-04-02 14:57:56 +02:00
throwError(SE_HERE, StringPrintf("EDS database with URI '%s' cannot be deleted, does not exist",
uri.c_str()));
EDS Client: implement creating and deleting databases Depends on the EDS 3.6 ESourceRegistry API. Needs the very latest EDS with the following commit. There's no configure check yet because EDS 3.6 is not released yet. commit 6df76009318eac9dbe3dd49165394d389102764e Author: Matthew Barnes <mbarnes@redhat.com> Date: Tue Sep 11 22:56:08 2012 -0400 Bug 683785 - Add e_source_new_with_uid() Variation of e_source_new() which allows a predetermined UID to be specified for a scratch source. This changes the "uid" property from read-only to read/write + construct-only, and eliminates the need for EServerSideSource to override the property.
2012-09-13 17:57:28 +02:00
}
GErrorCXX gerror;
if (!e_source_remove_sync(source, NULL, gerror)) {
code restructing: Exception, throwError() Raising exceptions via throwError() looses the original source code location information. Fixing that by explicitly passing that information as additional parameter, created with the preprocessor macro SE_HERE. Several files included the complex SyncContext.h only because needed throwError(). A better place for the revised implementation is the Exception class which used to be in util.h, now Exception.h. Simplifying the include statements exposed indirect include dependencies and removed "using namespace std" from the compilation of some source files which happened to rely on it. We want to get rid of that name space polution, so fix the code instead of adding it back.
2014-04-02 14:57:56 +02:00
throwError(SE_HERE, StringPrintf("deleting EDS database with URI '%s'", uri.c_str()),
EDS Client: implement creating and deleting databases Depends on the EDS 3.6 ESourceRegistry API. Needs the very latest EDS with the following commit. There's no configure check yet because EDS 3.6 is not released yet. commit 6df76009318eac9dbe3dd49165394d389102764e Author: Matthew Barnes <mbarnes@redhat.com> Date: Tue Sep 11 22:56:08 2012 -0400 Bug 683785 - Add e_source_new_with_uid() Variation of e_source_new() which allows a predetermined UID to be specified for a scratch source. This changes the "uid" property from read-only to read/write + construct-only, and eliminates the need for EServerSideSource to override the property.
2012-09-13 17:57:28 +02:00
gerror);
}
PIM: allow removal of data together with database removal (part of FDO #64835) There is a difference in EDS between removing the database definition from the ESourceRegistry (which makes the data unaccessible via EDS) and removing the actual database. EDS itself only removes the definition and leaves the data around to be garbage-collected eventually. This is not what we want for the PIM Manager API; the API makes a stronger guarantee that data is really gone. Fixed by introducing a new mode flag for the deleteDatabase() method and deleting the directory of the source directly in the EDS backend, if requested by the caller. The syncevolution command line tool will use the default mode and thus keep the data around, while the PIM Manager forces the removal of data.
2013-05-24 09:42:13 +02:00
if (removeData == REMOVE_DATA_FORCE) {
// Don't wait for evolution-source-registry cache-reaper to
// run, instead remove files ourselves. The reaper runs only
// once per day and also only moves the data into a trash
// folder, were it would linger until finally removed after 30
// days.
//
// This is equivalent to "rm -rf $XDG_DATA_HOME/evolution/*/<uuid>".
std::string basedir = StringPrintf("%s/evolution", g_get_user_data_dir());
if (isDir(basedir)) {
C++: simpler for loops boost/foreach.hpp is no longer needed, range-based loops work the same. With some helpers, even reverse iteration and boost::make_split_iterator() can be handled the same way. "auto" makes it possible to avoid explicitly spelling out the expected type. Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
2018-01-16 10:58:04 +01:00
for (const std::string &kind: ReadDir(basedir)) {
PIM: allow removal of data together with database removal (part of FDO #64835) There is a difference in EDS between removing the database definition from the ESourceRegistry (which makes the data unaccessible via EDS) and removing the actual database. EDS itself only removes the definition and leaves the data around to be garbage-collected eventually. This is not what we want for the PIM Manager API; the API makes a stronger guarantee that data is really gone. Fixed by introducing a new mode flag for the deleteDatabase() method and deleting the directory of the source directly in the EDS backend, if requested by the caller. The syncevolution command line tool will use the default mode and thus keep the data around, while the PIM Manager forces the removal of data.
2013-05-24 09:42:13 +02:00
std::string subdir = basedir + "/" + kind;
if (isDir(subdir)) {
C++: simpler for loops boost/foreach.hpp is no longer needed, range-based loops work the same. With some helpers, even reverse iteration and boost::make_split_iterator() can be handled the same way. "auto" makes it possible to avoid explicitly spelling out the expected type. Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
2018-01-16 10:58:04 +01:00
for (const std::string &source: ReadDir(subdir)) {
PIM: allow removal of data together with database removal (part of FDO #64835) There is a difference in EDS between removing the database definition from the ESourceRegistry (which makes the data unaccessible via EDS) and removing the actual database. EDS itself only removes the definition and leaves the data around to be garbage-collected eventually. This is not what we want for the PIM Manager API; the API makes a stronger guarantee that data is really gone. Fixed by introducing a new mode flag for the deleteDatabase() method and deleting the directory of the source directly in the EDS backend, if requested by the caller. The syncevolution command line tool will use the default mode and thus keep the data around, while the PIM Manager forces the removal of data.
2013-05-24 09:42:13 +02:00
// We assume that the UUID of the database
// consists only of characters which can be
// used in the directory name, i.e., no
// special encoding of the directory name.
if (source == uri) {
rm_r(subdir + "/" + source);
// Keep searching, just in case, although
// there should only be one.
}
}
}
}
}
}
EDS Client: implement creating and deleting databases Depends on the EDS 3.6 ESourceRegistry API. Needs the very latest EDS with the following commit. There's no configure check yet because EDS 3.6 is not released yet. commit 6df76009318eac9dbe3dd49165394d389102764e Author: Matthew Barnes <mbarnes@redhat.com> Date: Tue Sep 11 22:56:08 2012 -0400 Bug 683785 - Add e_source_new_with_uid() Variation of e_source_new() which allows a predetermined UID to be specified for a scratch source. This changes the "uid" property from read-only to read/write + construct-only, and eliminates the need for EServerSideSource to override the property.
2012-09-13 17:57:28 +02:00
}
EDS: added support for EDS 3.5.x When compiled against EDS 3.5.x or later, SyncEvolution now uses the backend code originally written for the EClient API introduced in EDS 3.2. That code was changed so that it works with the new include file rules and ESourceRegistry in EDS 3.5.x. Support for using the EClient API with EDS 3.4 was removed because maintaining three different flavors of the EDS backend code would be too much work and not gain much (just the possibility to test the EDSClient code with 3.4). At the moment, this is a compile time choice made automatically by configure. syncevolution.org binaries are compiled against an older EDS and thus do not work with EDS 3.5.x or later. EDS 3.5.x handles authentication itself, using a standard system prompt if necessary. SyncEvolution can no longer provide the password, and thus the "databaseUser/Password" options have no effect when using EDS 3.5.x. The patch leaves code for older EDS almost completely unchanged and therefore is considered safe for the stable release series leading to 1.3. Using EClient is an all-or-nothing choice now, because the common EvolutionSyncSource needs to be compiled differently. Thanks to the reorganized API, a lot more common code for ECal and EBook sources could be moved into EvolutionSyncSource.
2012-07-24 10:25:20 +02:00
#endif // USE_EDS_CLIENT
ESource *EvolutionSyncSource::findSource(const ESourceListCXX &list, const string &id )
redesigned SyncSource base class + API The main motivation for this change is that it allows the implementor of a backend to choose the implementations for the different aspects of a datasource (change tracking, item import/export, logging, ...) independently of each other. For example, change tracking via revision strings can now be combined with exchanging data with the Synthesis engine via a single string (the traditional method in SyncEvolution) and with direct access to the Synthesis field list (now possible for the first time). The new backend API is based on the concept of providing implementations for certain functionality via function objects instead of implementing certain virtual methods. The advantage is that implementors can define their own, custom interfaces and mix and match implementations of the different groups of functionality. Logging (see SyncSourceLogging in a later commit) can be done by wrapping some arbitrary other item import/export function objects (decorator design pattern). The class hierarchy is now this: - SyncSourceBase: interface for common utility code, all other classes are derived from it and thus can use that code - SyncSource: base class which implements SyncSourceBase and hooks a datasource into the SyncEvolution core; its "struct Operations" holds the function objects which can be implemented in different ways - TestingSyncSource: combines some of the following classes into an interface that is expected by the client-test program; backends only have to derive from (and implement this) if they want to use the automated testing - TrackingSyncSource: provides the same functionality as before (change tracking via revision strings, item import/export as string) in a single interface; the description of the pure virtual methods are duplicated so that developers can go through this class and find everything they need to know to implement it The following classes contain the code that was previously found in the EvolutionSyncSource base class. Implementors can derive from them and call the init() methods to inherit and activate the functionality: - SyncSourceSession: binds Synthesis session callbacks to virtual methods beginSync(), endSync() - SyncSourceChanges: implements Synthesis item tracking callbacks with set of LUIDs that the user of the class has to fill - SyncSourceDelete: binds Synthesis delete callback to virtual method - SyncSourceRaw: read and write items in the backends format, used for testing and backup/restore - SyncSourceSerialize: exchanges items with Synthesis engine using a string representation of the data; this is how EvolutionSyncSource has traditionally worked, so much of the same virtual methods are now in this class - SyncSourceRevisions: utility class which does change tracking via some kind of "revision" string which changes each time an item is modified; this code was previously in the TrackingSyncSource
2009-08-25 09:27:46 +02:00
{
Evolution Address Book: avoid picking CouchDB by default, again (MB #7877) The first attempt at solving this problem was incomplete. In addition to reordering the databases so that CouchDB databases are listed last (previous patch), we also must change the code so that the first database *after* reordering is marked as default *and* that actual syncs use that database. Therefore this patch changes EvolutionContactSource::getDatabases() so that the setting of m_isDefault is done at the end and EvolutionSyncSource::findSource() so that it looks at that result when no DB is selected explicitly.
2010-02-22 16:19:12 +01:00
string finalID;
if (!id.empty()) {
finalID = id;
} else {
EDS: added support for EDS 3.5.x When compiled against EDS 3.5.x or later, SyncEvolution now uses the backend code originally written for the EClient API introduced in EDS 3.2. That code was changed so that it works with the new include file rules and ESourceRegistry in EDS 3.5.x. Support for using the EClient API with EDS 3.4 was removed because maintaining three different flavors of the EDS backend code would be too much work and not gain much (just the possibility to test the EDSClient code with 3.4). At the moment, this is a compile time choice made automatically by configure. syncevolution.org binaries are compiled against an older EDS and thus do not work with EDS 3.5.x or later. EDS 3.5.x handles authentication itself, using a standard system prompt if necessary. SyncEvolution can no longer provide the password, and thus the "databaseUser/Password" options have no effect when using EDS 3.5.x. The patch leaves code for older EDS almost completely unchanged and therefore is considered safe for the stable release series leading to 1.3. Using EClient is an all-or-nothing choice now, because the common EvolutionSyncSource needs to be compiled differently. Thanks to the reorganized API, a lot more common code for ECal and EBook sources could be moved into EvolutionSyncSource.
2012-07-24 10:25:20 +02:00
// Nothing selected specifically, use the one marked as default.
C++: simpler for loops boost/foreach.hpp is no longer needed, range-based loops work the same. With some helpers, even reverse iteration and boost::make_split_iterator() can be handled the same way. "auto" makes it possible to avoid explicitly spelling out the expected type. Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
2018-01-16 10:58:04 +01:00
for (const Database &db: getDatabases()) {
Evolution Address Book: avoid picking CouchDB by default, again (MB #7877) The first attempt at solving this problem was incomplete. In addition to reordering the databases so that CouchDB databases are listed last (previous patch), we also must change the code so that the first database *after* reordering is marked as default *and* that actual syncs use that database. Therefore this patch changes EvolutionContactSource::getDatabases() so that the setting of m_isDefault is done at the end and EvolutionSyncSource::findSource() so that it looks at that result when no DB is selected explicitly.
2010-02-22 16:19:12 +01:00
if (db.m_isDefault) {
finalID = db.m_uri;
break;
}
}
}
EDS: added support for EDS 3.5.x When compiled against EDS 3.5.x or later, SyncEvolution now uses the backend code originally written for the EClient API introduced in EDS 3.2. That code was changed so that it works with the new include file rules and ESourceRegistry in EDS 3.5.x. Support for using the EClient API with EDS 3.4 was removed because maintaining three different flavors of the EDS backend code would be too much work and not gain much (just the possibility to test the EDSClient code with 3.4). At the moment, this is a compile time choice made automatically by configure. syncevolution.org binaries are compiled against an older EDS and thus do not work with EDS 3.5.x or later. EDS 3.5.x handles authentication itself, using a standard system prompt if necessary. SyncEvolution can no longer provide the password, and thus the "databaseUser/Password" options have no effect when using EDS 3.5.x. The patch leaves code for older EDS almost completely unchanged and therefore is considered safe for the stable release series leading to 1.3. Using EClient is an all-or-nothing choice now, because the common EvolutionSyncSource needs to be compiled differently. Thanks to the reorganized API, a lot more common code for ECal and EBook sources could be moved into EvolutionSyncSource.
2012-07-24 10:25:20 +02:00
#ifdef USE_EDS_CLIENT
C++: simpler for loops boost/foreach.hpp is no longer needed, range-based loops work the same. With some helpers, even reverse iteration and boost::make_split_iterator() can be handled the same way. "auto" makes it possible to avoid explicitly spelling out the expected type. Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
2018-01-16 10:58:04 +01:00
for (ESource *source: list) {
EDS: added support for EDS 3.5.x When compiled against EDS 3.5.x or later, SyncEvolution now uses the backend code originally written for the EClient API introduced in EDS 3.2. That code was changed so that it works with the new include file rules and ESourceRegistry in EDS 3.5.x. Support for using the EClient API with EDS 3.4 was removed because maintaining three different flavors of the EDS backend code would be too much work and not gain much (just the possibility to test the EDSClient code with 3.4). At the moment, this is a compile time choice made automatically by configure. syncevolution.org binaries are compiled against an older EDS and thus do not work with EDS 3.5.x or later. EDS 3.5.x handles authentication itself, using a standard system prompt if necessary. SyncEvolution can no longer provide the password, and thus the "databaseUser/Password" options have no effect when using EDS 3.5.x. The patch leaves code for older EDS almost completely unchanged and therefore is considered safe for the stable release series leading to 1.3. Using EClient is an all-or-nothing choice now, because the common EvolutionSyncSource needs to be compiled differently. Thanks to the reorganized API, a lot more common code for ECal and EBook sources could be moved into EvolutionSyncSource.
2012-07-24 10:25:20 +02:00
bool found =
!finalID.compare(e_source_get_display_name(source)) ||
!finalID.compare(e_source_get_uid(source));
if (found) {
return source;
}
}
#else
for (GSList *g = e_source_list_peek_groups (list.get()); g; g = g->next) {
redesigned SyncSource base class + API The main motivation for this change is that it allows the implementor of a backend to choose the implementations for the different aspects of a datasource (change tracking, item import/export, logging, ...) independently of each other. For example, change tracking via revision strings can now be combined with exchanging data with the Synthesis engine via a single string (the traditional method in SyncEvolution) and with direct access to the Synthesis field list (now possible for the first time). The new backend API is based on the concept of providing implementations for certain functionality via function objects instead of implementing certain virtual methods. The advantage is that implementors can define their own, custom interfaces and mix and match implementations of the different groups of functionality. Logging (see SyncSourceLogging in a later commit) can be done by wrapping some arbitrary other item import/export function objects (decorator design pattern). The class hierarchy is now this: - SyncSourceBase: interface for common utility code, all other classes are derived from it and thus can use that code - SyncSource: base class which implements SyncSourceBase and hooks a datasource into the SyncEvolution core; its "struct Operations" holds the function objects which can be implemented in different ways - TestingSyncSource: combines some of the following classes into an interface that is expected by the client-test program; backends only have to derive from (and implement this) if they want to use the automated testing - TrackingSyncSource: provides the same functionality as before (change tracking via revision strings, item import/export as string) in a single interface; the description of the pure virtual methods are duplicated so that developers can go through this class and find everything they need to know to implement it The following classes contain the code that was previously found in the EvolutionSyncSource base class. Implementors can derive from them and call the init() methods to inherit and activate the functionality: - SyncSourceSession: binds Synthesis session callbacks to virtual methods beginSync(), endSync() - SyncSourceChanges: implements Synthesis item tracking callbacks with set of LUIDs that the user of the class has to fill - SyncSourceDelete: binds Synthesis delete callback to virtual method - SyncSourceRaw: read and write items in the backends format, used for testing and backup/restore - SyncSourceSerialize: exchanges items with Synthesis engine using a string representation of the data; this is how EvolutionSyncSource has traditionally worked, so much of the same virtual methods are now in this class - SyncSourceRevisions: utility class which does change tracking via some kind of "revision" string which changes each time an item is modified; this code was previously in the TrackingSyncSource
2009-08-25 09:27:46 +02:00
ESourceGroup *group = E_SOURCE_GROUP (g->data);
GSList *s;
for (s = e_source_group_peek_sources (group); s; s = s->next) {
ESource *source = E_SOURCE (s->data);
syncevo: Renamed GString typedef in SmartPtr.h to GStringPtr. I was getting type ambiguity errors when cleaning up the header files. The ambiguity was with the glib GString. This may be able to be reverted once the namespace pollution is dealt with.
2011-06-17 11:53:59 +02:00
GStringPtr uri(e_source_get_uri(source));
Evolution Address Book: avoid picking CouchDB by default, again (MB #7877) The first attempt at solving this problem was incomplete. In addition to reordering the databases so that CouchDB databases are listed last (previous patch), we also must change the code so that the first database *after* reordering is marked as default *and* that actual syncs use that database. Therefore this patch changes EvolutionContactSource::getDatabases() so that the setting of m_isDefault is done at the end and EvolutionSyncSource::findSource() so that it looks at that result when no DB is selected explicitly.
2010-02-22 16:19:12 +01:00
bool found = finalID.empty() ||
!finalID.compare(e_source_peek_name(source)) ||
(uri && !finalID.compare(uri));
redesigned SyncSource base class + API The main motivation for this change is that it allows the implementor of a backend to choose the implementations for the different aspects of a datasource (change tracking, item import/export, logging, ...) independently of each other. For example, change tracking via revision strings can now be combined with exchanging data with the Synthesis engine via a single string (the traditional method in SyncEvolution) and with direct access to the Synthesis field list (now possible for the first time). The new backend API is based on the concept of providing implementations for certain functionality via function objects instead of implementing certain virtual methods. The advantage is that implementors can define their own, custom interfaces and mix and match implementations of the different groups of functionality. Logging (see SyncSourceLogging in a later commit) can be done by wrapping some arbitrary other item import/export function objects (decorator design pattern). The class hierarchy is now this: - SyncSourceBase: interface for common utility code, all other classes are derived from it and thus can use that code - SyncSource: base class which implements SyncSourceBase and hooks a datasource into the SyncEvolution core; its "struct Operations" holds the function objects which can be implemented in different ways - TestingSyncSource: combines some of the following classes into an interface that is expected by the client-test program; backends only have to derive from (and implement this) if they want to use the automated testing - TrackingSyncSource: provides the same functionality as before (change tracking via revision strings, item import/export as string) in a single interface; the description of the pure virtual methods are duplicated so that developers can go through this class and find everything they need to know to implement it The following classes contain the code that was previously found in the EvolutionSyncSource base class. Implementors can derive from them and call the init() methods to inherit and activate the functionality: - SyncSourceSession: binds Synthesis session callbacks to virtual methods beginSync(), endSync() - SyncSourceChanges: implements Synthesis item tracking callbacks with set of LUIDs that the user of the class has to fill - SyncSourceDelete: binds Synthesis delete callback to virtual method - SyncSourceRaw: read and write items in the backends format, used for testing and backup/restore - SyncSourceSerialize: exchanges items with Synthesis engine using a string representation of the data; this is how EvolutionSyncSource has traditionally worked, so much of the same virtual methods are now in this class - SyncSourceRevisions: utility class which does change tracking via some kind of "revision" string which changes each time an item is modified; this code was previously in the TrackingSyncSource
2009-08-25 09:27:46 +02:00
if (found) {
return source;
}
}
}
EDS: added support for EDS 3.5.x When compiled against EDS 3.5.x or later, SyncEvolution now uses the backend code originally written for the EClient API introduced in EDS 3.2. That code was changed so that it works with the new include file rules and ESourceRegistry in EDS 3.5.x. Support for using the EClient API with EDS 3.4 was removed because maintaining three different flavors of the EDS backend code would be too much work and not gain much (just the possibility to test the EDSClient code with 3.4). At the moment, this is a compile time choice made automatically by configure. syncevolution.org binaries are compiled against an older EDS and thus do not work with EDS 3.5.x or later. EDS 3.5.x handles authentication itself, using a standard system prompt if necessary. SyncEvolution can no longer provide the password, and thus the "databaseUser/Password" options have no effect when using EDS 3.5.x. The patch leaves code for older EDS almost completely unchanged and therefore is considered safe for the stable release series leading to 1.3. Using EClient is an all-or-nothing choice now, because the common EvolutionSyncSource needs to be compiled differently. Thanks to the reorganized API, a lot more common code for ECal and EBook sources could be moved into EvolutionSyncSource.
2012-07-24 10:25:20 +02:00
#endif
redesigned SyncSource base class + API The main motivation for this change is that it allows the implementor of a backend to choose the implementations for the different aspects of a datasource (change tracking, item import/export, logging, ...) independently of each other. For example, change tracking via revision strings can now be combined with exchanging data with the Synthesis engine via a single string (the traditional method in SyncEvolution) and with direct access to the Synthesis field list (now possible for the first time). The new backend API is based on the concept of providing implementations for certain functionality via function objects instead of implementing certain virtual methods. The advantage is that implementors can define their own, custom interfaces and mix and match implementations of the different groups of functionality. Logging (see SyncSourceLogging in a later commit) can be done by wrapping some arbitrary other item import/export function objects (decorator design pattern). The class hierarchy is now this: - SyncSourceBase: interface for common utility code, all other classes are derived from it and thus can use that code - SyncSource: base class which implements SyncSourceBase and hooks a datasource into the SyncEvolution core; its "struct Operations" holds the function objects which can be implemented in different ways - TestingSyncSource: combines some of the following classes into an interface that is expected by the client-test program; backends only have to derive from (and implement this) if they want to use the automated testing - TrackingSyncSource: provides the same functionality as before (change tracking via revision strings, item import/export as string) in a single interface; the description of the pure virtual methods are duplicated so that developers can go through this class and find everything they need to know to implement it The following classes contain the code that was previously found in the EvolutionSyncSource base class. Implementors can derive from them and call the init() methods to inherit and activate the functionality: - SyncSourceSession: binds Synthesis session callbacks to virtual methods beginSync(), endSync() - SyncSourceChanges: implements Synthesis item tracking callbacks with set of LUIDs that the user of the class has to fill - SyncSourceDelete: binds Synthesis delete callback to virtual method - SyncSourceRaw: read and write items in the backends format, used for testing and backup/restore - SyncSourceSerialize: exchanges items with Synthesis engine using a string representation of the data; this is how EvolutionSyncSource has traditionally worked, so much of the same virtual methods are now in this class - SyncSourceRevisions: utility class which does change tracking via some kind of "revision" string which changes each time an item is modified; this code was previously in the TrackingSyncSource
2009-08-25 09:27:46 +02:00
return NULL;
}
code restructing: Exception, throwError() Raising exceptions via throwError() looses the original source code location information. Fixing that by explicitly passing that information as additional parameter, created with the preprocessor macro SE_HERE. Several files included the complex SyncContext.h only because needed throwError(). A better place for the revised implementation is the Exception class which used to be in util.h, now Exception.h. Simplifying the include statements exposed indirect include dependencies and removed "using namespace std" from the compilation of some source files which happened to rely on it. We want to get rid of that name space polution, so fix the code instead of adding it back.
2014-04-02 14:57:56 +02:00
void EvolutionSyncSource::throwError(const SourceLocation &where, const string &action, GErrorCXX &gerror)
redesigned SyncSource base class + API The main motivation for this change is that it allows the implementor of a backend to choose the implementations for the different aspects of a datasource (change tracking, item import/export, logging, ...) independently of each other. For example, change tracking via revision strings can now be combined with exchanging data with the Synthesis engine via a single string (the traditional method in SyncEvolution) and with direct access to the Synthesis field list (now possible for the first time). The new backend API is based on the concept of providing implementations for certain functionality via function objects instead of implementing certain virtual methods. The advantage is that implementors can define their own, custom interfaces and mix and match implementations of the different groups of functionality. Logging (see SyncSourceLogging in a later commit) can be done by wrapping some arbitrary other item import/export function objects (decorator design pattern). The class hierarchy is now this: - SyncSourceBase: interface for common utility code, all other classes are derived from it and thus can use that code - SyncSource: base class which implements SyncSourceBase and hooks a datasource into the SyncEvolution core; its "struct Operations" holds the function objects which can be implemented in different ways - TestingSyncSource: combines some of the following classes into an interface that is expected by the client-test program; backends only have to derive from (and implement this) if they want to use the automated testing - TrackingSyncSource: provides the same functionality as before (change tracking via revision strings, item import/export as string) in a single interface; the description of the pure virtual methods are duplicated so that developers can go through this class and find everything they need to know to implement it The following classes contain the code that was previously found in the EvolutionSyncSource base class. Implementors can derive from them and call the init() methods to inherit and activate the functionality: - SyncSourceSession: binds Synthesis session callbacks to virtual methods beginSync(), endSync() - SyncSourceChanges: implements Synthesis item tracking callbacks with set of LUIDs that the user of the class has to fill - SyncSourceDelete: binds Synthesis delete callback to virtual method - SyncSourceRaw: read and write items in the backends format, used for testing and backup/restore - SyncSourceSerialize: exchanges items with Synthesis engine using a string representation of the data; this is how EvolutionSyncSource has traditionally worked, so much of the same virtual methods are now in this class - SyncSourceRevisions: utility class which does change tracking via some kind of "revision" string which changes each time an item is modified; this code was previously in the TrackingSyncSource
2009-08-25 09:27:46 +02:00
{
string gerrorstr;
if (gerror) {
gerrorstr += ": ";
gerrorstr += gerror->message;
} else {
gerrorstr = ": failure";
}
code restructing: Exception, throwError() Raising exceptions via throwError() looses the original source code location information. Fixing that by explicitly passing that information as additional parameter, created with the preprocessor macro SE_HERE. Several files included the complex SyncContext.h only because needed throwError(). A better place for the revised implementation is the Exception class which used to be in util.h, now Exception.h. Simplifying the include statements exposed indirect include dependencies and removed "using namespace std" from the compilation of some source files which happened to rely on it. We want to get rid of that name space polution, so fix the code instead of adding it back.
2014-04-02 14:57:56 +02:00
throwError(where, action + gerrorstr);
redesigned SyncSource base class + API The main motivation for this change is that it allows the implementor of a backend to choose the implementations for the different aspects of a datasource (change tracking, item import/export, logging, ...) independently of each other. For example, change tracking via revision strings can now be combined with exchanging data with the Synthesis engine via a single string (the traditional method in SyncEvolution) and with direct access to the Synthesis field list (now possible for the first time). The new backend API is based on the concept of providing implementations for certain functionality via function objects instead of implementing certain virtual methods. The advantage is that implementors can define their own, custom interfaces and mix and match implementations of the different groups of functionality. Logging (see SyncSourceLogging in a later commit) can be done by wrapping some arbitrary other item import/export function objects (decorator design pattern). The class hierarchy is now this: - SyncSourceBase: interface for common utility code, all other classes are derived from it and thus can use that code - SyncSource: base class which implements SyncSourceBase and hooks a datasource into the SyncEvolution core; its "struct Operations" holds the function objects which can be implemented in different ways - TestingSyncSource: combines some of the following classes into an interface that is expected by the client-test program; backends only have to derive from (and implement this) if they want to use the automated testing - TrackingSyncSource: provides the same functionality as before (change tracking via revision strings, item import/export as string) in a single interface; the description of the pure virtual methods are duplicated so that developers can go through this class and find everything they need to know to implement it The following classes contain the code that was previously found in the EvolutionSyncSource base class. Implementors can derive from them and call the init() methods to inherit and activate the functionality: - SyncSourceSession: binds Synthesis session callbacks to virtual methods beginSync(), endSync() - SyncSourceChanges: implements Synthesis item tracking callbacks with set of LUIDs that the user of the class has to fill - SyncSourceDelete: binds Synthesis delete callback to virtual method - SyncSourceRaw: read and write items in the backends format, used for testing and backup/restore - SyncSourceSerialize: exchanges items with Synthesis engine using a string representation of the data; this is how EvolutionSyncSource has traditionally worked, so much of the same virtual methods are now in this class - SyncSourceRevisions: utility class which does change tracking via some kind of "revision" string which changes each time an item is modified; this code was previously in the TrackingSyncSource
2009-08-25 09:27:46 +02:00
}
#endif // HAVE_EDS
introduced "namespace SyncEvo" consistently Added syncevo/declarations.h, which has This is now used for all SyncEvolution source files, except for the GTK UI, which is written in plain C. In the library it helps to avoid name clashes. The reason for using defines instead of spelling out "namespace SyncEvo" is twofold: 1. if that should ever become necessary, it is easier to rename the namespace via configure options by changing the define 2. editors don't indent the whole file content
2009-10-02 17:23:53 +02:00
SE_END_CXX