2009-05-11 16:31:17 +02:00
|
|
|
/*
|
|
|
|
* 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
|
|
|
|
*/
|
|
|
|
|
2009-03-30 21:34:01 +02:00
|
|
|
#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"
|
2009-03-30 21:34:01 +02:00
|
|
|
|
|
|
|
|
|
|
|
DBusSyncClient::DBusSyncClient(const string &server,
|
2009-04-17 17:45:40 +02:00
|
|
|
const map<string, int> &source_map,
|
2009-04-01 13:30:52 +02:00
|
|
|
void (*progress) (const char *source,int type,int extra1,int extra2,int extra3,gpointer data),
|
2009-03-30 21:34:01 +02:00
|
|
|
void (*server_message) (const char *message,gpointer data),
|
2009-05-29 09:38:14 +02:00
|
|
|
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),
|
2009-03-30 21:34:01 +02:00
|
|
|
gpointer userdata) :
|
2009-04-17 17:45:40 +02:00
|
|
|
EvolutionSyncClient(server, true, getSyncSources (source_map)),
|
|
|
|
m_source_map (source_map),
|
2009-04-01 08:50:47 +02:00
|
|
|
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)
|
2009-03-30 21:34:01 +02:00
|
|
|
{
|
|
|
|
}
|
|
|
|
|
|
|
|
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)
|
2009-04-17 17:45:40 +02:00
|
|
|
{
|
|
|
|
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
|
|
|
}
|
2009-04-17 17:45:40 +02:00
|
|
|
setSyncModes (sources, modes);
|
2009-04-22 08:13:39 +02:00
|
|
|
|
2009-04-27 13:41:35 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
bool DBusSyncClient::getPrintChanges() const
|
|
|
|
{
|
|
|
|
return false;
|
2009-04-17 17:45:40 +02:00
|
|
|
}
|
|
|
|
|
2009-09-25 11:08:59 +02:00
|
|
|
string DBusSyncClient::askPassword(const string &passwordName, const string &descr, const ConfigPasswordKey &key)
|
2009-03-30 21:34:01 +02:00
|
|
|
{
|
2009-05-29 09:38:14 +02:00
|
|
|
string retval;
|
|
|
|
char *password = NULL;
|
2009-04-01 08:50:47 +02:00
|
|
|
if (!m_need_password)
|
2009-05-29 09:38:14 +02:00
|
|
|
throwError(string("Password query not supported"));
|
|
|
|
|
|
|
|
password = m_need_password (getUsername (), getSyncURL(), m_userdata);
|
|
|
|
if (password)
|
|
|
|
retval = string (password);
|
|
|
|
return retval;
|
2009-03-30 21:34:01 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
void DBusSyncClient::displayServerMessage(const string &message)
|
|
|
|
{
|
2009-04-01 08:50:47 +02:00
|
|
|
m_server_message (message.c_str(), m_userdata);
|
2009-03-30 21:34:01 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
void DBusSyncClient::displaySyncProgress(sysync::TProgressEventEnum type,
|
|
|
|
int32_t extra1, int32_t extra2, int32_t extra3)
|
|
|
|
{
|
2009-04-01 13:30:52 +02:00
|
|
|
m_progress (NULL, type, extra1, extra2, extra3, m_userdata);
|
2009-05-08 09:15:23 +02:00
|
|
|
EvolutionSyncClient::displaySyncProgress(type, extra1, extra2, extra3);
|
2009-03-30 21:34:01 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
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,
|
2009-03-30 21:34:01 +02:00
|
|
|
int32_t extra1, int32_t extra2, int32_t extra3)
|
|
|
|
{
|
2009-07-30 16:31:19 +02:00
|
|
|
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);
|
2009-05-08 09:15:23 +02:00
|
|
|
EvolutionSyncClient::displaySourceProgress(type, source, extra1, extra2, extra3);
|
2009-03-30 21:34:01 +02:00
|
|
|
}
|
2009-04-01 14:32:55 +02:00
|
|
|
|
|
|
|
bool DBusSyncClient::checkForSuspend()
|
|
|
|
{
|
|
|
|
return m_check_for_suspend (m_userdata);
|
|
|
|
}
|
2009-09-21 06:20:03 +02:00
|
|
|
|
|
|
|
int DBusSyncClient::sleep (int intervals)
|
|
|
|
{
|
|
|
|
time_t start = time(NULL);
|
|
|
|
while (true) {
|
2009-10-01 20:40:17 +02:00
|
|
|
g_main_context_iteration(NULL, FALSE);
|
2009-09-21 06:20:03 +02:00
|
|
|
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;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|