[SyncEvolution] configuration parameters: command line update
by Patrick Ohly
Hello!
I'd like to solicit some feedback about configuring local sync, in
particular command line options for it. I'm still debating this with
myself, so consider the following email as "thinking aloud"...
As you might remember from the "local sync" mail thread, local sync uses
two configurations (using a "foo" server implementing some protocol
"bar" as example):
1. "source" config @foo defines sources which access "foo" using
the "bar" protocol; source-config@foo provides additional
per-peer settings like a URL or username/password
2. "sync" config foo has syncURL=local://@foo and does a sync
involving local databases (the same ones also used with other
peers) and the databases accessible via @foo
The original plan was to avoid the need for the source-config@foo
settings. But that neglected that credentials for "foo" should be tried
to the @foo context, instead of putting them elsewhere, and that there
was no other property which could have been used for the URL, to name
just one example.
This setup with two configs leads to two usability problems:
* How can such a config be created from a template? "syncevolution
--configure foo" would be nice.
* How can properties of both contexts be modified in a single
command? This is necessary for the single configure command
above and for running a sync.
Related to this is the question:
* How can multiple source properties be set in a single command?
Not being able to do that has made the instructions for
configuring SyncEvolution as a server unnecessarily complex.
Syntax for property values
==========================
Currently there is "--[sync|source]-property <property>=<value>".
<property> is the name of one of the builtin properties. I can imagine
extending this syntax as follows:
[<config>/]<property>[/<source>]=<value> (syntax I)
where <config> is a configuration name (which may contain @ signs) and
<source> is a source name (like "addressbook"). The rational for
introducing the slash as separator is that neither config nor source
names are allowed to contain it.
Examples:
evolutionsource=My Address Boook
evolutionsource/addressbook=My Address Book
@foo/evolutionsource/addressbook=Foo's Address Book
The drawback is that splitting the left side of the assignment is
ambiguous. In "foo/bar", either "foo" or "bar" could be the property
name. This can only be decided when property names are well-known. Typos
would break this detection, leading to bad error messages.
So perhaps the following syntax would be better:
[<source>/]<property>[@<config>]=<value> (syntax II)
The ordering of source, property and config is more natural:
addressbook/evolutionsource=My Address Book
syncURL@foo=local://@foo
But now the meaning of @ is overloaded:
syncURL@source-config@foo=Foo's URL
That is not a problem for a syntax parser, but less readable. The
ambiguity is resolved by declaring that @foo always a context.
I prefer the second syntax. Any other opinions?
As before, unqualified properties apply to all sources and all configs.
Templates for local sync
========================
The current set of templates provide properties for just one
configuration, the one which uses SyncML to talk to a server or a
client. Creating a local sync involves creating two configs.
There is no 1:1 mapping between the two. It is possible to define the
@foo sources, then synchronize them with a) the @default sources with
foo@default and b) with a second set of sources in @bar config with
foo@bar.
In the "syncevolution --configure foo" invocation, "foo" is the name of
the sync config. But what is the name of the source config? I propose
the following heuristic:
* if syncURL=local:// (no explicit context): use @foo for peer
name foo[@context]
* if syncURL=local://@bar: use @bar
That way a command line user still has the chance to override the source
context name, while the right thing will happen by default. Examples:
syncevolution --configure \
--sync-property username=xyz \
--sync-property password=abc \
foo
=> create or update @foo and foo, setting username/password in both
because they apply to both contexts
syncevolution --configure \
--sync-property syncURL=local://@bar \
foo
=> create or update @bar and foo; credentials must have been set in
@bar before
A template for "foo" then might look like this:
--------------------
=== template.ini ===
fingerprint = Foo Server
description = sync with Foo using protocol Bar
=== config.ini ===
PeerIsClient = 1
syncURL = local://
=== sources/addressbook/config.ini ===
sync = two-way
uri = addressbook
=== config.ini@source-config@foo ===
syncURL = http://foo.com/
=== sources/addressbook/config.ini@foo ===
uri = /contacts
type = Bar Protocol
--------------------
In the D-Bus interface, this would be returned by GetConfig() with "" as
key for "config.ini", "source-config@foo" for config.ini inside the
source-config@foo config, "sources/addressbook" for
sources/addressbook/config.ini and sources/addressbook@foo for
sources/addressbook/config.ini@foo.
My hope is that sync-ui will simply preserve these additional entries in
the hash. When it does a "SetConfig()" call with the modified hash
(credentials inserted, sync mode for "adddressbook" set), these
additional entries tell the syncevo-dbus-server to do its magic and also
configure the @foo context. The advantage is that no or only minimal
changes to sync-ui and D-Bus interface will be needed.
The drawback is that this additional magic increases the complexity. For
example, SetConfig() is called for the "foo" config, but suddenly ends
up modifying a different config.
Password handling in local sync
===============================
Credentials in the sync config are not needed for the sync itself,
because the peer is part of the same process. But users and frontends
like the GTK sync-ui are used to setting credentials in the sync config.
Therefore I suggest that local sync should always apply sync credentials
to the context it is synchronizing with, if they are set in the sync
config. If they are empty, the values from the source config are used.
Make --sync-property/--source-property optional
===============================================
A purely cosmetic change. It has irked me for a long time that the
command line was not able to determine automatically what username=foo
means. It had to be told explicitly that this is a property assignment,
and more specifically, a sync property (--sync-property username=foo).
This was necessary because theoretically, there might be sync and source
properties with the same name. But that would be confusing and thus was
avoided (and should be in the future).
That leaves the question of distinguishing parameters and the config
name from property assignments. That's easy, anything starting with a
dash is a parameter, anything with an equal sign an assignment. Explicit
--sync-property and --source-property parameters can be used to resolve
ambiguities.
--
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, 11 months
[SyncEvolution] Using SyncEvolution for data conversion
by Frederik Elwert
Hello!
I am currently looking for a Linux replacement for Gigaset QuickSync
[1]. QuickSync is a tool to sync contacts with a cordless phone (not a
cell phone). I thought SyncEvolution might be the obvious candidate for
this.
The cordless phone talks BlueTooth, but not SyncML. I just figured out
that one can feed contacts to it by pushing 2.1 vCards one by one over
BlueTooth. I am currently only interested Desktop → Phone sync. Since
SyncEvolution over Bluetooth won’t work, I thought I could at least use
SyncEvolution to convert my Evolution addressbook to a set of vCard
files in 2.1 format.
As far as I understand, I’d normally need backend-to-backend sync
(Evolution → file). IIRC, that’s not yet implemented. So I thought about
setting up a local SyncEvolution server with the file backend. But it
seems that it isn’t possible to sync syncevolution with
syncevo-http-server on the same machine.
So is there a way to achieve what I try to do using SyncEvolution? Maybe
someone can push me into the right direction.
Thanks,
Frederik
[1] http://gigaset.com/de/de/cms/PageQuickSync.html
11 years
[SyncEvolution] Contacts rejected by peer
by Hevï Guy
Once I finally set-up Syncevolution 1.1.1-2 so that I could at least do
a one-way refresh of "Contacts" to my Nokia N86 8MP, I found that
certain contacts would not sync; The resulting comment in the GUI was:
"There were 22 remote rejections". Has anybody else experienced this?
More importantly, has anybody found a solution?
11 years
[SyncEvolution] building 1.1.99.4 with gcc 4.6
by Peter Robinson
Hi Patrick,
I was testing 1.1.99.4 to ensure it at least compiled on Fedora
rawhide (F-16) and found I needed the attached patch to compile with
gcc 4.6
Regards,
Peter
11 years
[SyncEvolution] Akonadi status update
by Patrick Ohly
Hello!
Since merging the Akonadi code, I focused on stabilizing and testing in
preparation for 1.1.99.4. I wanted to get a new update out this week;
unfortunately I am not yet ready to include Akonadi in the binaries or
the nightly testing.
Here are the details:
* I re-did the vCard extensions to avoid affecting non-Akonadi
syncs. Dinesh, please review the commit and re-test with
Akonadi. So far I only verified that the existing nightly
testing continues as it did before the merge.
* I fixed various other, minor build issues.
* I updated the reference build platform from Ubuntu Hardy 8.04 to
Ubuntu Lucid 10.04. Both are long-term support releases. The
advantage is that 10.04 contains a recent enough Akonadi; on
8.04 the code didn't compile cleanly. So theoretically,
syncevolution.org binaries can now be built including EDS and
Akonadi support.
Open issues:
* When KDE is active, crashes are caught by KApplication, which
leads to a GUI dialog about reporting the crash. This might be
useful, but where does it report the problem to? Can this be
disabled if it turns out to be not so useful?
* If both Akonadi and EDS are enabled and installed, which backend
does "backend = addressbook/calendar/todo/memo" choose? Both EDS
and Akonadi backends recognize such generic names. The original
goal was to let the person compiling SyncEvolution decide (by
only enabling the desired backend) or the user (by installing
only the right backend). The latter depends on packaging
backends separately, which is not currently done for
syncevolution.org binaries. There is only
"syncevolution-evolution".
Note that I had always intentionally added the -evolution suffix to
denote the package for EDS. I could try to create "syncevolution" core,
"syncevolution-evolution" and "syncevolution-kde". Not sure how easy
that is. Either way, I would prefer and additional solution:
* Introduce a SyncConfig::isPlatform(type) with type ==
GNOME/KDE/... plus possibly other values.
* EDS backends only react to generic names if platform == GNOME.
* Akonadi only if platform == KDE.
* The check itself can be based on the KDE env variable, at the
moment. If not set, assume GNOME.
* The KWallet check also needs to use isPlatform().
Later on we can make isPlatform() more sophisticated and even
configurable via a global config option.
Dinesh, can you prepare and test a patch for these issues?
About testing Akonadi sources, should this be based on Ovi or some of
the more mainstream servers, like Memotoo? In my testing with Ovi, I had
quite a lot of problems with network errors and timeouts.
Essentially we'll have to run EDS<->server and Akonadi<->server tests
independently of each other. That a server works well with EDS is no
guarantee that it'll work equally well with Akonadi: for simple tests
not involving specific data, it shouldn't matter, but in particular for
testItems it matters a lot. For that test, we also need KDE specific
test cases.
ical20.ics might be identical for KDE and EDS, but vcard30.vcf is
definitely EDS specific. Dinesh, can you provide a corresponding file
for KDE?
--
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.
11 years
[SyncEvolution] Contacts rejected by peer
by HeviiGuy
Once I finally set-up Syncevolution 1.1.1-2 so that I could at least do
a one-way refresh of "Contacts" to my Nokia N86 8MP, I found that
certain contacts would not sync; The resulting comment in the GUI was:
"There were 22 remote rejections". Has anybody else experienced this?
More importantly, has anybody found a solution?
11 years
[SyncEvolution] Nokia N86 8MP
by HeviiGuy
After having suffered a BIG crash and then re-installing everything, my
previously-temperamental syncing of calendar items and memos is now
non-existent (thanks to recent assistance, my "contacts" sync well!). If
anybody is successfully syncing with a Nokia N86 8MP, could you please
post the config settings which you are using. If nobody has this phone,
typical config settings from other Nokia owners would likely be very
helpful as well so that I can try various possibilities.
If this may help, here are my present settings:
/peers/myfone/sources/address/config.ini
sync = two-way
type = addressbook
uri = Contacts
/peers/myfone/sources/calendar/config.ini
sync = two-way
type = calendar:text/calendar
uri = Calendar
/peers/myfone/sources/calendar+todo/config.ini
sync = none
type = virtual:text/x-calendar:1.0
uri = Calendar
/peers/myfone/sources/memo/config.ini
sync = two-way
type = memo:text/plain
uri = Notes
/peers/myfone/sources/todo/config.ini
sync = disabled
type = todo
uri = task
/soures/addressbook/config.ini
type = addressbook
evolutionsource = ShuFone
/soures/calendar/config.ini
type = calendar:text/calendar
evolutionsource = HeviiCalendar
/soures/calendar+todo/config.ini
type = virtual:text/x-calendar:1.0
evolutionsource = HeviiCalendar,HeviiTasks
/soures/memo/config.ini
type = memo
evolutionsource = HeviiMemos
/soures/todo/config.ini
type = todo
evolutionsource = HeviiTasks
11 years
[SyncEvolution] Horde: "unexpected reply from server"
by Tobias Pfaff
syncevolution-evolution_1.1.1-2_i386 0.6.2maverick1
Horde 3.3.11
Evolution 2.30.3/Ubuntu
I'm trying to sync my calendar and contacts from Evolution with Horde
(My goal is to keep my Android phone synced with Evolution, but that'll
be the next step.)
Syncing contacts seems to work fine, but there appears to be a timeout
when syncing the calendar. According to syncevolution's output it sends
more than 400 entries to Horde, but in Horde's database there are only
114 entries.
This is syncevolution's output:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
tobias@telemach:~$ syncevolution horde
[INFO] todo: inactive
[INFO] memo: inactive
[INFO] addressbook: inactive
[INFO] calendar: starting first time sync, two-way
[INFO] calendar: first time sync done unsuccessfully
[ERROR] unexpected slow sync (local, status 22000)
Synchronization failed, see
/home/tobias/.cache/syncevolution/horde-2011-04-19-18-44/syncevolution-log.html
for details.
Changes applied during synchronization:
+---------------|-----------------------|-----------------------|-CON-+
| | LOCAL | REMOTE | FLI |
| Source | NEW | MOD | DEL | ERR | NEW | MOD | DEL | ERR | CTS |
+---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+
| calendar | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| slow, 0 KB sent by client, 0 KB received |
| unexpected slow sync (local, status 22000) |
+---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+
| start Tue Apr 19 18:44:53 2011, duration 0:06min |
| unexpected slow sync (local, status 22000) |
+---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+
First ERROR encountered: unexpected slow sync (local, status 22000)
Doing a slow synchronization may lead to duplicated items or
lost data when the server merges items incorrectly. Choosing
a different synchronization mode may be the better alternative.
Restart synchronization of affected source(s) with one of the
following sync modes to recover from this problem:
slow, refresh-from-server, refresh-from-client
Analyzing the current state:
syncevolution --status horde calendar
Running with one of the three modes:
syncevolution --sync [slow|refresh-from-server|refresh-from-client]
horde calendar
[ERROR] command line execution failure
tobias@telemach:~$ syncevolution --sync refresh-from-client horde calendar
[INFO] todo: inactive
[INFO] memo: inactive
[INFO] addressbook: inactive
[INFO] calendar: starting first time sync from client
Local data changes to be applied remotely during synchronization:
*** calendar ***
Comparison was impossible.
[INFO] calendar: sent 1/1913
[INFO] calendar: sent 2/1913
(... and so forth ...)
[INFO] calendar: sent 408/1913
[INFO] calendar: sent 409/1913
[ERROR] unexpected reply from server; might be a temporary problem, try
again later
[INFO] resend previous message, retry #1
[ERROR] unexpected reply from server; might be a temporary problem, try
again later
[INFO] resend previous message, retry #2
[ERROR] unexpected reply from server; might be a temporary problem, try
again later
[INFO] resend previous message, retry #3
[ERROR] unexpected reply from server; might be a temporary problem, try
again later
[INFO] Transport giving up after 3 retries and 6:04min
[ERROR] transport failed, retry period exceeded
[INFO] calendar: first time sync done unsuccessfully
[ERROR] aborted on behalf of user (local, status 20017)
Synchronization failed, see
/home/tobias/.cache/syncevolution/horde-2011-04-19-18-47/syncevolution-log.html
for details.
Changes applied during synchronization:
+---------------|-----------------------|-----------------------|-CON-+
| | LOCAL | REMOTE | FLI |
| Source | NEW | MOD | DEL | ERR | NEW | MOD | DEL | ERR | CTS |
+---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+
| calendar | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| refresh-from-client, 0 KB sent by client, 0 KB received |
| item(s) in database backup: 1913 before sync, 1913 after it |
| aborted on behalf of user (local, status 20017) |
+---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+
| start Tue Apr 19 18:47:53 2011, duration 6:54min |
| external transport failure (local, status 20043) |
+---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+
First ERROR encountered: unexpected reply from server; might be a
temporary problem, try again later
Data modified locally during synchronization:
*** calendar ***
no changes
[ERROR] command line execution failure
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
I can't see the server's "unexpected replies", if they are logged
somewhere, I will be happy to provide them here.
Can I tell syncevolution to just send a limited number of entries per
run initially?
Regards, Tobias
--
Tobias Pfaff
Bochum
11 years
[SyncEvolution] Can't run syncevolution on Ubuntu 10.10
by Oleg Sevostyanov
Hello.
I try to run syncevolution 1:1.1.1-2 on Ubuntu 10.10 and get error
[ERROR] starting D-Bus session failed:
org.freedesktop.DBus.Error.UnknownMethod
[INFO] syncevo-dbus-server is most likely too old
What I must to do to fix this problem.
--
Oleg Sevostyanov
11 years
[SyncEvolution] packagers: system upgrade?
by Patrick Ohly
Hello folks!
Debian users have tried out installing more recent SyncEvolution
packages and ran into issues that apply to all distros shipping
SyncEvolution. I'd like to raise awareness of these issues and discuss
how to solve them.
SyncEvolution depends on features in recent libsynthesis, for example
additional XML tags. Running SyncEvolution with an old libsynthesis will
trigger XML parser errors.
First problem: because the ABI of libsynthesis has not changed, the
soname of libsynthesis has not been changed either. If I had, older code
using libsynthesis would have unnecessarily been prevented from using
the more recent libsynthesis. To solve this, add versioned dependencies
to your SyncEvolution packages. To be on the safe side, please assume
that SyncEvolution always depends on the version of libsynthesis that it
is bundled with.
Second problem: syncevo-dbus-server might be running while packages are
updated, which leads to the situation that it uses an old libsynthesis
in memory.
I'm not entirely sure how to solve that second problem. I could try
dynamic loading of libsynthesis, but that only covers the libsynthesis
dependency and not the update of SyncEvolution itself, nor of any of the
other shared libraries in use by the process. If anyone has suggestions
for how user-space restarts are meant to be handled by distros, then
please let me know.
--
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.
11 years
