[SyncEvolution] bridgie syncml server and caldav/card dav server
by Robert Schetterer
Hi, is there a chance to use syncevolution
as a bridge between a syncml server and a caldav/carddav server and vice
versa
i.e horde or funambol server syncml and DAViCal etc
--
Best Regards
MfG Robert Schetterer
Germany/Munich/Bavaria
10 years, 1 month
[SyncEvolution] Syncevolution build system conversion
by Krzesimir Nowak
Hi.
My name is Krzesimir Nowak. I work for Openismus GmbH who asked me to
try to convert Syncevolution's build system to a (simpler) non-recursive
Automake build. I now have something that works, with no obvious
regressions.
I've been working in a remote branch (I branched from Chris Kuehl's
dbus-server-reorganization because that already has some improvements
and it looks like it will get into master first).
https://meego.gitorious.org/~krnowak/meego-middleware/syncevo-autotools-c...
but I have also attached it as one patch, which might be easier to
review.
This should be simpler and more robust (for instance, against weird
linker problems), with less duplication, and it allows faster builds via
make -j.
It also removes the pre/post configure system and the *-gen.am system
which can be unfamiliar to regular users of autotools.
Patrick's minimum requirement was to still have the version number
autogenerated from the git version, and I have managed to keep that.
Patrick also preferred not having to list all the templates and config
files, but I have only partly achieved that.
I think it would be wise to make further step-by-step improvements once
this first step is in master. For instance, see:
https://meego.gitorious.org/~krnowak/meego-middleware/syncevo-autotools-c...
Regards,
Krzesimir
10 years, 4 months
[SyncEvolution] Online contacts in Harmattan
by Ove Kåven
While I'm at it, someone told me that on the N950 (Harmattan), when he
was logged onto Facebook, SyncEvolution would try to include his entire
Facebook friend list in the sync, which is unfortunate.
Before I spend too much time looking into it myself (I don't have much
of it, after all), do you know an obvious way in QtContacts to suppress
such online contacts, so that only contacts that are actually stored in
the device's own database would be synced?
10 years, 6 months
[SyncEvolution] command line: item operations (BMC #23783)
by Patrick Ohly
Hello!
I've extended the command line and would like to get feedback on the
patch before merging into the command line. If you are a user of the
command line, does the following change make sense to you?
Author: Patrick Ohly <patrick.ohly(a)intel.com> 2011-11-21 17:38:34
Committer: Patrick Ohly <patrick.ohly(a)intel.com> 2011-11-21 17:38:34
Parent: 2d591e780dcfb8470d16e28aa87b52d0b754b8de (config: return value + "was set" for each config property)
Branch: pohly
Follows: syncevolution-1-2
Precedes:
command line: config and source names are optional (BMC #23783)
The need to add "foo" and "bar" pseudo config and source names to the
command line even when all parameters for the operation where
explicitly specified on the command line was confusing.
Now it is possible to invoke item operations without the config and
source name. Names which refer to non-existent configs are still
accepted, as in previous releases. Typos are handled better by
producing a detailed error report which includes (as applicable):
- config doesn't exist
- source doesn't exist or not selected
- backend property not set
This error report is created only if SyncSource was unable to create a
SyncSource, which is detected by catching the status exception with
the right error code. Trying to anticipate the error at the Cmdline
level would duplicate code found in the SyncSource and/or impose
limitations which might not hold in all cases.
Because luids used to be positional arguments after <config> and
<source>, a new --luids keyword is necessary to indicate that the
following parameters are luids and not <config> and <source>.
Added a CmdlineTest::testItemOperations for this new command line
syntax. It uses the file backend to run some real operations (missing
earlier).
Error reporting in the command line uses the same mix of writing error
messages and returning early (Cmdline) and throwing exceptions (rest
of SyncEvolution). Perhaps the Cmdline class should also use
exceptions - but not now.
---------------------------------- README.rst ----------------------------------
index 16bb95c..b6de21f 100644
@@ -42,20 +42,23 @@ Create, update or remove a configuration:
syncevolution --remove|--migrate <options> [--] <config>
List items:
- syncevolution --print-items [--] <config> <source>
+ syncevolution --print-items [--] [<config> [<source>]]
Export item(s):
- syncevolution [--delimiter <string>] --export <dir>|<file>|- [--] <config> <source> [<luid> ...]
+ syncevolution [--delimiter <string>] --export <dir>|<file>|- [--] [<config> [<source> [<luid> ...]]]
+ --luids <luid> ...
Add item(s):
- syncevolution [--delimiter <string>|none] --import <dir>|<file>|- [--] <config> <source>
+ syncevolution [--delimiter <string>|none] --import <dir>|<file>|- [--] [<config> [<source>]]
+ --luids <luid> ...
Update item(s):
syncevolution --update <dir> [--] <config> <source>
syncevolution [--delimiter <string>|none] --update <file>|- [--] <config> <source> <luid> ...
+ --luids <luid> ...
Remove item(s):
syncevolution --delete-items [--] <config> <source> (<luid> ... | '*')
@@ -419,10 +422,10 @@ the peer during the next synchronization. If the peer somehow
needs to get a clean copy of all local items, then use ``--sync
refresh-from-local`` in the next run. ::
syncevolution --print-items <config> <source>
- syncevolution [--delimiter <string>] --export <dir>|<file>|- <config> <source> [<luid> ...]
- syncevolution [--delimiter <string>|none] --import <dir>|<file>|- <config> <source>
+ syncevolution [--delimiter <string>] --export <dir>|<file>|- [<config> [<source> [<luid> ...]]]
+ syncevolution [--delimiter <string>|none] --import <dir>|<file>|- [<config> <source>]
syncevolution --update <dir> <config> <source>
syncevolution [--delimiter <string>|none] --update <file>|- <config> <source> <luid> ...
syncevolution --delete-items <config> <source> (<luid> ... | *)
@@ -430,17 +433,24 @@ Restore depends on the specific format of the automatic backups
created by SyncEvolution. Arbitrary access to item data is provided
with additional options. <luid> here is the unique local identifier
assigned to each item in the source, transformed so that it contains
only alphanumeric characters, dash and underscore. A star * in
---delete-items selects all items for deletion.
+--delete-items selects all items for deletion. There are two ways
+of specifying luids: either as additional parameters after the
+config and source parameters (which may be empty in this case, but
+must be given) or after the ``--luids`` keyword.
-<config> and <source> must be given, but they do not have to refer to
-existing configurations. In that case, the desired backend and must be
-give via the ``backend`` property, like this::
+<config> and <source> may be given to define the database which is to
+be used. If not given or not refering to an existing configuration
+(which is not an error, due to historic reasons), the desired backend
+must be given via the ``backend`` property, like this::
- syncevolution --print-items backend=evolution-contacts dummy-config dummy-source
+ syncevolution --print-items backend=evolution-contacts
+ syncevolution --export - backend=evolution-contacts \
+ --luids pas-id-4E33F24300000006 pas-id-4E36DD7B00000007
The desired backend database can be chosen via ``database=<identifier>``.
+See ``--print-databases``.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
10 years, 6 months
[SyncEvolution] regular expression library: boost Xpressive?
by Patrick Ohly
Hello!
SyncEvolution does not make use of regular expressions because it wants
to avoid a dependency on libraries which are not common enough to be
relied upon on all target platforms. That rules out Qt RegEx.
It also avoids libraries whose ABI varies too often, because it would
complicate delivering libraries via syncevolution.org. That has ruled
out anything from Boost which is more than a set of header files, like
boost::regex (libboost_regex.so.1.42.0 in Debian Stable, still in
Testing, but bound to be replaced by libboost_regex.so.1.46.0).
Another aspect is C++ support for std::string and the desire to do
search/replace. Otherwise POSIX regex support in GNU libc would be an
option.
I've just come across another alternative: boost::Xpressive.
http://www.boost.org/doc/libs/1_47_0/doc/html/xpressive/user_s_guide.html...
This is old enough (introduced in Boost 1.34.0) to not limit compilation
on older Linux distros and it is header-only.
It supports regular expression syntax, parsed at runtime. It also touts
its own C++ "domain language" for statically compiling regular
expressions as an alternative.
I am less certain about the later. While the approach looks neat, it is
also not going to be familiar for many developers, which makes the code
less approachable.
For example:
sregex re = '$' >> +_d >> '.' >> _d >> _d;
That's the same as:
sregex re = sregex::compile("$\\d\\.\d\d");
Any thoughts about using Boost Xpressive in SyncEvolution from other
developers? Any alternatives?
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
10 years, 6 months
[SyncEvolution] syncevo-dbus-server + forking processes
by Patrick Ohly
Hello!
Chris is going to work on running syncs inside a process forked from the
main syncevo-dbus-server. Before diving into the planning and
implementation, let me outline the background.
At the moment, syncevo-dbus-server is one process (when ignoring local
sync for a second) which handles D-Bus calls and syncs at the same time.
A sync involves operations which can block for a long time, so keeping
the D-Bus part alive and responsive is challenging. It involves hacks
like entering and leaving the main event loop, checking it inside
libsoup, etc.
Local sync already uses a second forked process so that it can run
client and server engines concurrently.
Getting rid of the current hacks is one motivation for running syncs in
a forked process. The main process would enter the main loop once and
never return unless it was asked to shut down.
The other is that (eventually) it'll allow to run a "clean" main process
which never loads any of the backend modules. That may help to keep the
permanent memory footprint smaller than it is today. Right now this is
not possible because merely registering a backend requires loading it.
Fixing that is outside of the current scope.
Resource leaks inside a sync become less problematic when the process
running the sync can shut down.
Here are some requirements for "sync in forked process":
* should be disabled when running outside of the D-Bus daemon
(syncevolution command line in non-daemon mode, client-test
testing)
* interactive password requests through D-Bus must continue to
work
* abort/suspend requests via D-Bus must work
* the forked process should shut down cleanly, so that "valgrind
--follow-child=yes --leak-check=yes" provides sane results (the
forked process in a local sync currently fails to do that,
because it is forked in a less controlled environment and
therefore just calls _exit())
* logging:
* the main syncevo-dbus-server process should use syslog
logging for its own messages, without redirecting
stdout/stderr
* the forked process should start redirecting
stdout/stderr into the normal logging mechanism (so that
library error messages are visible when running the
syncevolution command line as client of the D-Bus server
and, later, they appear in log files) and switch to a
session log when the session is ready
Somewhat related to this work is support for push sync. I suspect that
this will also use forked processes to monitor remote and local
databases without interfering with the main process. It would be good if
the mechanism for forking and communication between process was generic
and not tied to syncing alone.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
10 years, 6 months
[SyncEvolution] Update on work to port syncevo-dbus-server to GIO GDBus
by Chris Kühl
Hi,
For a while now I've been working on porting the syncevo-dbus-server
to use the GIO dbus implementation, GDBus. This is a configure time
option that can be explicitly set using the --with-gio-gdbus flag or,
if no flag is given, looks for an adequate version of GIO and, if
found, builds with GIO GDBus.
The work is taking place on the gio-gdbus branch. The code changes in
the dbus/server/ files have only been made to make things work with
both implementations. The GIO GDBus implmentation lives in the
src/gdbusxx directory.
Work is now being done to correct failures that the test-dbus.py
script bring up. Currently there are no more errors but 23 failures.
This is compared to 11 failures when running the test-dbus.py script
on the master branch.
One side issue... Late last week, I ran into an issue when using the
-O0 gcc flag. It was generating invalid code from the
MethodHandler::add method. With the other optimization levels this
doesn't occur. I'm not sure if this should be considered an issue as
it seems to be a known issue[1] in GCC.
Here are a list of the failures that are unique to each dbus implementation.
==============================================================
:: GIO GDBus only::
==============================================================
FAIL TestConnection.testCredentialsRight - send correct credentials
FAIL TestConnection.testCredentialsWrong - send invalid credentials
FAIL TestConnection.testKillInactive - block server with client A,
then let client B connect twice
FAIL TestConnection.testStartSync - send a valid initial SyncML message
FAIL TestConnection.testStartSyncTwice - send the same SyncML message
twice, starting two sessions
FAIL TestConnection.testTimeoutSync - start a sync, then wait for
server to detect that we stopped replying
FAIL TestDBusServerTerm.testNoTerm - D-Bus server must stay around during calls
FAIL TestDBusSession.testSecondSession - a second session should not
run unless the first one stops
FAIL testDBusSyncError.testSyncNoConfig - Executes a real sync with no
corresponding config.
FAIL TestLocalSync.testConcurrency - D-Bus server must remain
responsive while sync runs
FAIL TestLocalSync.testSync - run a simple slow sync between local dirs
FAIL TestSessionAPIsDummy.testAutoSyncLocalConfigError - test that
auto-sync is triggered for local sync, fails due to permanent config
error here
FAIL TestSessionAPIsDummy.testAutoSyncLocalSuccess - test that
auto-sync is done successfully for local sync between file backends
FAIL TestSessionAPIsDummy.testAutoSyncNetworkFailure - test that
auto-sync is triggered, fails due to (temporary?!) network error here
FAIL TestSessionAPIsDummy.testGetConfigWithTempConfig - test the
config is gotten for a new temporary config.
FAIL TestSessionAPIsDummy.testRestoreByRef - restore data before or
after a given session
==============================================================
:: Bluez GDBus only::
==============================================================
FAIL TestDBusServerPresence.testPresenceSignal - check Server.Presence signal
FAIL TestDBusServerPresence.testServerCheckPresence - check
Server.CheckPresence()
FAIL TestDBusServerPresence.testSessionCheckPresence - check
Session.CheckPresence()
And here are the failures that both implementations have in common.
==============================================================
:: Common issues::
==============================================================
FAIL TestFileNotify.testRestart - set up auto sync, then check that
server restarts
FAIL TestSessionAPIsDummy.testGetConfigWithTempConfig - test the
config is gotten for a new temporary config.
FAIL TestSessionAPIsDummy.testInteractivePassword - test the info
request is correctly working for password
FAIL TestSessionAPIsDummy.testUpdateConfigTemp - test the config is
just temporary updated but no effect in storage.
FAIL TestSessionAPIsReal.testSync - run a real sync with default
server and test status list and progress number
FAIL TestSessionAPIsReal.testSyncSecondSession - ask for a second
session that becomes ready after a real sync
FAIL TestSessionAPIsReal.testSyncStatusAbort - test status is set
correctly when the session is aborted
FAIL TestSessionAPIsReal.testSyncStatusSuspend - test status is set
correctly when the session is suspended
Cheers,
Chris
[1] http://blog.flameeyes.eu/2010/06/14/mailbox-does-gcc-miscompile-at-o0
10 years, 6 months
[SyncEvolution] SyncEvolution 1.2.1 released
by Patrick Ohly
SyncEvolution 1.2.1
===================
Maintenance release with various bug fixes.
* GTK UI + config: fix "custom server" setup (BMC #13511)
When the "default" config template (= ScheduleWorld) was downgraded to
"not consumer ready" in SyncEvolution 1.1.0.99.1, setting up a custom
SyncML service in the GTK UI stopped working because the UI wouldn't
show the "not consumer ready" config.
The problem described above is deterministic and fixed now.
Initially the problem seemed to be random. So perhaps there is
also another, related issue.
* phone sync: delete<->delete conflict + phone calendar+todo sync (BMC #23744)
When deleting an item on phone and locally, the next sync failed with
ERROR messages about "object not found". Retrying the sync then worked.
* Nokia: prevent accidental usage of "calendar" or "todo" sources
Nokia phones use a combined "calendar+todo" source for syncing. The
"calendar" and "todo" sources also exist because that is where local
databases are configured.
In such a setup, syncing always has to use "calendar+todo". For example,
to refresh from the Linux desktop to the phone, use:
--sync refresh-from-server <config> calendar+todo
To work with items (restore, show local content), use the underlying sources,
as in:
--print-items <config> calendar
It was possible to accidentally sync with the "calendar". This commit
prevents that by adding an invalid URI setting to the "calendar" and
"todo" sources in the Nokia and Ovi templates. Existing configs are not
touched, so beware when you already have configured your Nokia phone.
* vCard: X- chat extensions were limited to one instance per kind
For example, only one Jabber account could be synchronized. This
was caused by an incomplete definition of the conversion to and from
vCard.
* syncevo-dbus-server + phone sync: catch SIGPIPE to avoid premature exit
Frederik Elwert reported that running a local sync with a phone via
Bluetooth caused the syncevo-dbus-server to shut down during a sync.
Explicitly telling the process to ignore the SIGPIPE signal solved that
problem.
* syncevo-http-server: support chained SSL certificates
So far, the file pointed to by --certificate-file had to
contain the server certificated (signed by a CA known to the client)
and (optionally) a client certificate. Now the file may also contain
additional intermediate certificates which will be sent to the client
(chained certificates).
* documentation: added glossary and command line conventions sections,
improved listing of properties, embedd property definitions in man page,
README and README.html
* EDS compatibility: fixed inconsistency in libecal check
The check for the _r variants in libical still used an older max
version. This might have prevented using them (if not found) or
could have led to a mixture of old and new libecal in the same
process (probably crashed).
* glib: avoid including glib/*.h headers directly
Recent glib deprecates the direct inclusion of some of its headers,
in favor of including glib.h. Doing that here whenever possible, so
perhaps it now compiles on Fedora 17 (untested).
Upgrading from releases before 1.2
==================================
Old configurations can still be read. But writing, as it happens
during a sync, must migrate the configuration first. Release 1.2
automatically migrates configurations. The old configurations
will still be available (see "syncevolution --print-configs") but must
be renamed manually to use them again under their original names with
older SyncEvolution releases.
Source, Installation, Further information
=========================================
http://syncevolution.org/blogs/pohly/2011/syncevolution-121-released
Source snapshots are in
http://downloads.syncevolution.org/syncevolution/sources
i386, lpia and amd64 binaries for Debian-based distributions are
available via the "stable" syncevolution.org repository. Add the
following entry to your /apt/source.list, then install
"syncevolution-evolution":
deb http://downloads.syncevolution.org/apt unstable main
These binaries include the "sync-ui" GTK GUI and were compiled for
Ubuntu 8.04 LTS (Hardy). Older distributions like Debian 4.0 (Etch) can
no longer be supported with precompiled binaries because of missing
libraries, but the source still compiles when not enabling the GUI (the
default).
The same binaries are also available as .tar.gz and .rpm archives in
http://downloads.syncevolution.org/syncevolution/evolution. In contrast
to 0.8.x archives, the 1.x .tar.gz archives have to be unpacked and the
content must be moved to /usr, because several files would not be found
otherwise.
After installation, follow the
http://syncevolution.org/documentation/getting-started steps.
--
Patrick Ohly, on behalf of everyone who has helped
to make SyncEvolution possible:
http://syncevolution.org/about/contributors
10 years, 6 months
[SyncEvolution] ActiveSync contact support
by Patrick Ohly
Hello!
I'm currently looking at the eas<->vCard 3.0 conversion in activesyncd.
It is partly broken (one cannot do strcpy of the BDAY value between the
two, the format is different; EMAIL without attribute was ignored).
That's easy enough to fix, but there's a more fundamental issue.
ActiveSync has a fixed data model, which in the case of contacts only
supports:
* three different email addresses (without a way to mark them as
work/home/other)
* two postal addresses (one work, one home)
* ten different phone numbers:
* two business voice
* two home voice
* one business fax
* one business fax
* one cell
* one car
* one radio (whatever that means nowadays)
* one pager
This is a subset of what vCard supports. Conversion to vCard is possible
without data loss.
The challenge now is: should the vCard to EAS conversion try to be smart
and preserve as much data as possible, or should it set what it can and
ignore the rest?
For email, the current approach is to fill the three slots with the
first three EMAIL properties. There's not much that can be done
differently.
For postal addresses it becomes more interesting: if a vCard has two
WORK ADR, should one be stored as business and the other as home
address? At least it would be stored, albeit with the wrong type.
Same for things like cell phone. I'm certain that some of my address
book entries have more than one TEL with TYPE=CELL.
Right now I am leaning towards keeping activesyncd simple. Let it store
vCards that match the EAS data model, but don't worry about those who
don't.
That pushes the problem towards SyncEvolution. It doesn't make it easier
to solve, but that's where the solution conceptually belongs.
On the other hand, SyncEvolution doesn't really know about these
limitations of a specific ActiveSync server. I bet it does depend on the
specific ActiveSync protocol revision, which is not exposed to
SyncEvolution at the moment - at least not via the libeassync API.
I could rant now about the pros and cons of a fixed data model that is
specified as part of a synchronization protocol. There are advantages,
but only as long as you don't need anything that isn't included. With
Evolution<->Google synchronization via ActiveSync we'll have the
"ironic" situation that both sides support arbitrary number of phone
numbers, but they can't synchronize that against each other.
With ActiveSync, that is a limitation of the protocol. With SyncML, the
limitation is often in the implementation - not better in practice, but
at least it could be fixed :-/ For example, Google's SyncML
implementation doesn't support BDAY, although it could.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
10 years, 7 months
[SyncEvolution] SyncEvolution 1.2.1 in preparation
by Patrick Ohly
Hello!
Does anyone need anything fixed in 1.2.1?
Various smaller (and one larger) fixes have accumulated on the
maintenance branch. If I don't hear otherwise, then I will get the ball
rolling on packaging and pushing a 1.2.1 update.
Here's what I have so far (from the NEWS file):
* GTK UI + config: fix "custom server" setup (BMC #13511)
When the "default" config template (= ScheduleWorld) was downgraded to
"not consumer ready" in SyncEvolution 1.1.0.99.1, setting up a custom
SyncML service in the GTK UI stopped working because the UI wouldn't
show the "not consumer ready" config.
The problem described above is deterministic and fixed now.
Initially the problem seemed to be random. So perhaps there is
also another, related issue.
* phone sync: delete<->delete conflict + phone calendar+todo sync (BMC #23744)
When deleting an item on phone and locally, the next sync failed with
ERROR messages about "object not found". Retrying the sync then worked.
* Nokia: prevent accidental usage of "calendar" or "todo" sources
Nokia phones use a combined "calendar+todo" source for syncing. The
"calendar" and "todo" sources also exist because that is where local
databases are configured.
In such a setup, syncing always has to use "calendar+todo". For example,
to refresh from the Linux desktop to the phone, use:
--sync refresh-from-server <config> calendar+todo
To work with items (restore, show local content), use the underlying sources,
as in:
--print-items <config> calendar
It was possible to accidentally sync with the "calendar". This commit
prevents that by adding an invalid URI setting to the "calendar" and
"todo" sources in the Nokia and Ovi templates. Existing configs are not
touched, so beware when you already have configured your Nokia phone.
* syncevo-dbus-server + phone sync: catch SIGPIPE to avoid premature exit
Frederik Elwert reported that running a local sync with a phone via
Bluetooth caused the syncevo-dbus-server to shut down during a sync.
Explicitly telling the process to ignore the SIGPIPE signal solved that
problem.
* documentation: added glossary and command line conventions sections,
improved listing of properties, embedd property definitions in man page,
README and README.html
* EDS compatibility: fixed inconsistency in libecal check
The check for the _r variants in libical still used an older max
version. This might have prevented using them (if not found) or
could have led to a mixture of old and new libecal in the same
process (probably crashed).
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
10 years, 7 months
