The XMLRPC backend allows to connect to a webmail or PIM application by
means of XMLRPC, to use the application as data store for syncevolution.
It depends on the xmlrpc-c library.
The unit test part is not finished and left as copied from the file
backend for later completion.
The copyright is waived as documented in the files.
Use gnome-keyring to store and retrieve passwords in dbus server
by default when dbus server is compiled with gnome-keyring library.
For storing passwords, if failed in gnome-keyring, an error will
be thrown, which aborts flushing properties.
For retrieving passwords, firstly find them in the gnome-keyring.
If it is not found, dbus server then send InfoRequest signal to
dbus clients to ask for passwords. See MB#6376.
Set the "consumerReady" flag for the ZYB service, so now
it is going to be listed in the sync UI. Also set 'calendar'
as 'disabled' for offical announcement says it won't be
supported.
According to synthesis, mapentries have type (TMapEntryType), for a server side
implementation, it is possible to have multiple mapentries with the same localid
and differeciated by entry type (such as tempidmap and pendingmap).
e_cal_get_object() seems to run into situations where it neither sets
the "comp" pointer nor returns an error. SyncEvolution was using an
uninitialized pointer in that case. Set the "comp" pointer to NULL
to detect this kind of failure => "ERROR retrieving item...".
The EDS backend was asking for glib support even when it was not
active. In combination with not linking against the right libs
in that case there was a link failure because g_thread_init()
and g_type_init() were not found.
When the EDS backend was active, this wasn't a problem because
the necessary libs were linked indirectly.
This patch reduces the number of libs that are checked and used
when not enabling the EDS backend. This is done by resetting
the ECAL/EBOOK flags when inactive and only asking for glib
when active.
It also fixes the checking and linking against gobject and gthread
in the case that glib support is requested.
Out-of-memory errors were not handled correctly:
- The code using realloc() might have leaked a string.
- A static pointer was used to avoid further memory
allocation errors, but the caller then would have
freed it => try strdup() and check result in caller
instead.
"git show-ref" printed two hashes, one for the local branch and one
for the remote branch. This broke the rest of the script. We want
only the local branch hash, which is what the "--heads" option is for.
When the config name is "" or "@xxx"(only with context the peer
name is empty), return all reports of different peers in the
specified logdir. They are sorted by their creation time,
which are encoded in their dir names.
Context info is not recorded in the logdir or directory name.
Normally different logdirs are used for different contexts to
distinguish them. If some contexts share the same logdir,
then all sessions are returned if only context is specified no
matter which context the sessions belong to.
The key 'peer' is also stored in every report dictionary sent to
dbus clients. To get it from the dir name, a new method
'getPeerNameFromLogdir' is added in the class 'LogDir'.
Also fix a bug of reports oder. Return reports in descending
order, which means the newest report at first.
Change the unit tests of test-dbus.py for ordering problem
and the peer name is empty. Add some new logging dirs to
test the ordering when the peer name is empty.
Step information 'waiting' is appended into status for the
progress spinner. The spinner should be disabled unless 'waiting'
is explicitly appended in the status.
'waiting' means the dbus server is blocked and waiting for something,
typically IO events, such as sending data, waiting for response. Once
it is absent from status, the dbus server is done with waiting.
Change corresponding unit tests in the test-dbus.py for statuses
have been changed.
This change was necessary because it turned out that using
g_dbus_setup_bus() and later dbus_g_bus_get() leads to problems
(assertion about watch data on Moblin 2.1, CRITICAL warning
and possibly other issues on Debian Lenny).
It seems that sharing a DBusConnection between different layers on top
of libdbus is either not supported or incorrectly implemented, at
least in glib-dbus.
The problem was found in SyncEvolution when using a libecal/ebook
which call D-Bus under the hood (Moblin Bugzilla #8460). SyncEvolution
has no control over those calls, therefore making the connection used
by the syncevo-dbus-server private was the easier alternative.
"syncevolution --configure" works by copying the config with modified
properties set as filters. This did not work for adding sources because
SyncContext::copy() only worked on *existing* sources.
Changed the semantic of the sourceFilter parameter in
SyncContext::copy() so that it specifies *exactly* which sources are
to be copied instead of acting as a filter.
If the given set is a subset of the existing sources, this does not
change anything (SyncContext.cpp dummy.copy(*this, &activeSources)).
If the given set is a superset, then now the additional sources will
be copied where they were ignored before (Cmdline.cpp). There are no
other calls to SyncConfig::copy(), so this change is safe.
Added a new CmdlineTest to cover this situation.
Two bugs fixed here:
1. status handler could potentially be called several times with "idle"
2. the StatusChanged handler did things differently from GetStatus
An invalid type (like inactive backend, or something the user
entered into the file manually) raises an exception when accessing
the source parameters. This exception must be caught and transformed
into the SourceUnusable exception expected by D-Bus clients.
An unset type leads to a NULL SyncSource pointer. This was checked,
but without raising an exception. CheckSource() thus incorrectly
reported success.
Shutting down a sync session because of user-requested abort does not
cancel pending messages, because that would be allowed to block. Instead
the transport agent is destructed.
The SoupTransportAgent did not cancel the pending message and
therefore callbacks for a stale instance of it were invoked later on
*if* the main loop was activated again. This can only happen in the
syncevo-dbus-server, not the command line.
Shutting down a sync session because of user-requested abort does not
cancel pending messages, because that would be allowed to block. Instead
the transport agent is destructed.
The SoupTransportAgent did not cancel the pending message and
therefore callbacks for a stale instance of it were invoked later on
*if* the main loop was activated again. This can only happen in the
syncevo-dbus-server, not the command line.
Apply temporary configs when calling other APIs
of sessions. This makes configs that users temporarily
set affect other APIs.
All sources filters in m_sourceFilters must be set
to config not only for existing sources in config but also
for non-existing sources. This could help users temporarily
do some operations without flushing any configs.
Currently affected APIs are Session.CheckSource,
Session.GetDatabases, Session.GetConfig, Session.Sync.
Also add 3 unit tests for CheckSource, GetDatabases
and GetConfig to test the temporary config is in
effect for them. They all are passed.
'getSyncSources' of SyncConfig only returns shared sources
in shared layout and peer sources in other layouts.
Peer sources must also be included in shared layout. Moreover,
new sources in sources filters should be taken into consideration.
It should return an union of:
1. contextpath/sources
2. peers/[one-peer]/sources
3. sources in sources filter
Implement 3 unit tests for status and 1 unit test for
progress. For status,
1) test a full status list when a sync is executed
This is checked in TestSessionAPIsReal.testSync
2) test status when session is aborted
3) test status when session is suspended
For progress, test progress number is increasing
when a sync is executed. Also combine this check in
TestSessionAPIsReal.testSync
It is necessary to specify own signal receivers in
subclasses of DBusUtil to let them add new operations.
Two methods "progressChanged" and "statusChanged" are
added in DBusUtil. They are called when handling
statusChanged and progressChanged signals in setUpListeners.
By checking progress in "progressChanged", we can
make sure that aborting or suspending takes place when
sync is running.
SESSION_END always flushes status no matter whether
there is any change of status. It will duplicate
status and send them to dbus clients.
Only send StatusChanged signal when there is a change
of status.
This problem was found by the unit test which will
check any two adjacent statuses should not be the same.
The status 'SYNC_RUNNING' should be set firstly
in Session.run instead of setting it when
SESSION_START event is reported. This could mislead
dbus clients.
Instead of fetching a specific repo, use just "git fetch" to
pull updates into an existing repo. Specifying the repo
should have worked, but apparently is not done correctly (not
yet?) by the git in Debian Stable.
Using "git fetch" assumes that the URL of the repo does not
change between updates. That should be the case for us.
In a setup where it was run inside schroot we got error
messages from schroot because gconfd got stuck and prevented
a clean unmount of /tmp. Even "kill -9" wouldn't get rid of
such a hanging gconfd.
As a workaround, running the setup command twice seems to
succeed, including getting rid of the handing gconfd.
Previously do cleanup operation after implementing
a syncevolution setup. But if this setup raises
exceptions, we might get incorrect test results.
so clean all these files before doing any other
preparations
move 'evolution-prebuilt' summary from interoperability test
to client::source. Write xml and xsl codes to generate
html output to show its testing results.
Checking out a branch which only exists remotely requires
a bit more work. Checking out tags might also have failed
due to an unnecessary "git pull". Now "git tag" and "git branch"
are used to check what the requested revision is and do the
necessary opertions.
The "prebuilt" test ran, but because it used the build directory
of the current platform it didn't find any backends, or the wrong
ones. Fixed by only using the backend setting from the previous
testing if the directory really exists and falling back to the
relative "backends" directory otherwise.
It might be possible to always use "backends". In order to not
change the running testing this wasn't done.
