syncevolution/src/DBusSyncClient.cpp

124 lines
4.2 KiB
C++
Raw Normal View History

/*
* 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 "DBusSyncClient.h"
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
#include "SyncSource.h"
DBusSyncClient::DBusSyncClient(const string &server,
const map<string, int> &source_map,
void (*progress) (const char *source,int type,int extra1,int extra2,int extra3,gpointer data),
void (*server_message) (const char *message,gpointer data),
char* (*need_password) (const char *username, const char *server_url, gpointer data),
2009-04-01 14:32:55 +02:00
gboolean (*check_for_suspend)(gpointer data),
gpointer userdata) :
EvolutionSyncClient(server, true, getSyncSources (source_map)),
m_source_map (source_map),
m_userdata (userdata),
m_progress (progress),
m_server_message (server_message),
2009-04-01 14:32:55 +02:00
m_need_password (need_password),
m_check_for_suspend (check_for_suspend)
{
}
DBusSyncClient::~DBusSyncClient()
{
}
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
void DBusSyncClient::prepare(const std::vector<SyncSource *> &sources)
{
SyncModes modes (SYNC_NONE);
map<string,int>::const_iterator iter;
for (iter = m_source_map.begin (); iter != m_source_map.end (); iter++) {
modes.setSyncMode (iter->first, (SyncMode)iter->second);
2009-04-22 08:13:39 +02:00
}
setSyncModes (sources, modes);
2009-04-22 08:13:39 +02:00
}
bool DBusSyncClient::getPrintChanges() const
{
return false;
}
string DBusSyncClient::askPassword(const string &passwordName, const string &descr, const ConfigPasswordKey &key)
{
string retval;
char *password = NULL;
if (!m_need_password)
throwError(string("Password query not supported"));
password = m_need_password (getUsername (), getSyncURL(), m_userdata);
if (password)
retval = string (password);
return retval;
}
void DBusSyncClient::displayServerMessage(const string &message)
{
m_server_message (message.c_str(), m_userdata);
}
void DBusSyncClient::displaySyncProgress(sysync::TProgressEventEnum type,
int32_t extra1, int32_t extra2, int32_t extra3)
{
m_progress (NULL, type, extra1, extra2, extra3, m_userdata);
EvolutionSyncClient::displaySyncProgress(type, extra1, extra2, extra3);
}
void DBusSyncClient::displaySourceProgress(sysync::TProgressEventEnum type,
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
SyncSource &source,
int32_t extra1, int32_t extra2, int32_t extra3)
{
m_progress (g_strdup (source.getName()), type, extra1, extra2,
// Synthesis engine doesn't count locally
// deleted items during
// refresh-from-server. That's a matter of
// taste. In SyncEvolution we'd like these
// items to show up, so add it here.
(type == sysync::PEV_DSSTATS_L &&
source.getFinalSyncMode() == SYNC_REFRESH_FROM_SERVER) ?
source.getNumDeleted() :
extra3,
m_userdata);
EvolutionSyncClient::displaySourceProgress(type, source, extra1, extra2, extra3);
}
2009-04-01 14:32:55 +02:00
bool DBusSyncClient::checkForSuspend()
{
return m_check_for_suspend (m_userdata);
}
int DBusSyncClient::sleep (int intervals)
{
time_t start = time(NULL);
while (true) {
g_main_context_iteration(NULL, FALSE);
time_t now = time(NULL);
if (m_check_for_suspend(m_userdata)) {
return (intervals - now + start);
}
if (intervals - now + start <=0) {
return intervals - now +start;
}
}
}