[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.
9 years, 1 month
[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.
9 years, 3 months
[SyncEvolution] Akonadi + KDE support (was: Re: [Opensync-devel] OpenSync: fragmentation is harmful)
by Patrick Ohly
[moving to SyncEvolution list]
On Di, 2011-01-04 at 10:30 -0800, Emanoil Kotsev wrote:
> Hi,
>
> I need to catch up with the thread, but for now I want to answer to this here
>
> --- On Mon, 1/3/11, Patrick Ohly <patrick.ohly(a)gmx.de> wrote:
>
> > have). GPE is one example. Akonadi another. I already wrote
> > a prototype
> > backend for Akonadi, but now need a developer who is
> > motivated to finish
> > and maintain it.
I should have mentioned that Dinesh is working on it; I just haven't
seen the result yet and don't know whether he wants to stay around once
it is included (maintenance!).
> If you give me access to the code I could fix it, as I am highly
> motivated to have KDE4 sincable in near future (until someone fixes
> the rest of opensync).
Dinesh, is there a chance that Emanoil helps with the SyncEvolution
Akonadi backend? I can imagine that the work can be split up easily (for
example, you doing the KDE integration (HTTP, KWallet, GUI), while
Emanoil does the actual sync backend), but you know best what the
current status is.
Emanoil, attached Dinesh's last email on the subject. None of his work
is in the main SyncEvolution. We did one code review a while back and
determined that further work was needed to make it ready.
I'd be very interested to get as many suitable patches integrated now.
1.2 (= master) is still in an experimental phase, so modifying core code
is okay. The Akonadi backend can be modified at any time, it is just a
question of when it is ready for users.
--
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.
9 years, 4 months
Re: [SyncEvolution] Memotoo: updating event + todo ignored?
by Patrick Ohly
On Mi, 2011-03-16 at 13:48 +0000, Thomas Pequet wrote:
> Ok try again, I have disable the test to LAST-MODIFIED.
> So now ?
Pass! Hurray! :-)
--
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.
9 years, 4 months
[SyncEvolution] Sony Ericsson K800 umlaute
by Patrick Ohly
Hello!
A user contacted me regarding special characters (German umlaute)
getting mangled when synchronizing with a Sony Ericsson K800. It turned
out that the phone, in violation of the SyncML spec, uses ISO-8859-1
encoding of its vCard data. Worse, it does so without adding the CHARSET
property.
There is a workaround in libsynthesis. It is possible to override the
encoding for a specific phone. The attached file can be dropped into
~/.config/syncevolution-xml/remoterules/server/00_sony_ericsson.xml and
the default charset for all Sony Ericsson phones will be ISO-8859-1.
This is not a proper solution, though:
- not all Sony Ericsson phones are broken like that
- of those which are, some might use a different local charset
I'm uncertain how to address this problem. At the very least we need a
configure option which sets the fallback charset, because on a Linux
system with UTF-8 it is simply impossible to determine what national
charset the user might have on his old phone.
Any suggestions?
--
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.
9 years, 4 months
Re: [SyncEvolution] syncing calendar with nokia 6303 fails
by Patrick Ohly
On Fr, 2011-03-11 at 09:13 +0000, Haug Bürger wrote:
> I get the red box, see Synchronisation.jpeg, only if I set the last
> checkbox "Termine & Aufgaben", see CalendarCheckmark.jpeg. If the last
> check mark is not set the synchronisation is successful. I can sync
> notes and contacts.
>
> I found "Never received status for command 'SyncHdr',..." near the end
> of the log file which looked strange to me.
That's not the main problem. The phone stops talking to the PC:
[2011-03-11 09:51:05.602] OBEX Request 3 got a failed response Not found
[2011-03-11 09:51:05.603] TransportException thrown at /work/runtests/head/syncevolution/src/syncevo/ObexTransportAgent.cpp:408
[2011-03-11 09:51:05.603] ObexTransprotAgent: Underlying transport error
I'm afraid I have no idea why the phone refuses to cooperate here.
--
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.
9 years, 4 months
Re: [SyncEvolution] Error when syncing a particular event
by Patrick Ohly
On Mi, 2011-03-09 at 18:56 +0000, Tino Keitel wrote:
> On Wed, Mar 09, 2011 at 08:17:54 -0800, Patrick Ohly wrote:
> > On Mi, 2011-03-09 at 15:17 +0000, Tino Keitel wrote:
> > > [ERROR] calendar: retrieving item: -rid: Cannot retrieve calendar
> > > object path: Object not found
> >
> > Can you send me the full log at loglevel=4 where such a problem occurs?
> > If you can't reproduce it, please send me the log where this problem
> > above occurred ("syncevolution --print-sessions").
>
> Attached.
Thanks. Can you also send me the log file of the server for such a
failure? The client receives a Delete command without any IDs in it,
that's what leads to the error above. The root cause is on the server
side.
> I deleted the above event, now it happens with another one.
How did you know which event to delete?
> > What version of Evolution are you using?
>
> 1.1.1a at the client and the server.
What backend do you use? File backend or EDS? If it is Evolution, which
version of it?
--
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.
9 years, 5 months
[SyncEvolution] syncing calendar with nokia 6303 fails
by Haug Bürger
I use Ubuntu 10.10 with syncevolution form downloads.syncevolution.org
(1.1.1). I was successful in syncing contacts, notes with my Nokia 6303
classic phone using bluetooth.
But I was not able to sync my calendar. I found the following in the log
files.
Any ideas what's wrong?
Haug
#
–
[2011-03-03 09:33:32.869] 'DSStateChange' - Datastore changes state,
datastore=calendar+todo, oldstate=completed, newstate=idle [--][++]
[->end]
–[2011-03-03 09:33:32.869] End of 'DSStateChange' [->top]
# [2011-03-03 09:33:32.869] fTempGUIDMap: removing 0 items
# [2011-03-03 09:33:32.869] fTempGUIDMap: removing 0 items
# [2011-03-03 09:33:32.869] fTempGUIDMap: removing 0 items
# [2011-03-03 09:33:32.869] fTempGUIDMap: removing 0 items
# [2011-03-03 09:33:32.869] fTempGUIDMap: removing 0 items
# [2011-03-03 09:33:32.869] fTempGUIDMap: removing 0 items
# [2011-03-03 09:33:32.869] fTempGUIDMap: removing 0 items
# [2011-03-03 09:33:32.869] fTempGUIDMap: removing 0 items
# [2011-03-03 09:33:32.869] fTempGUIDMap: removing 0 items
# [2011-03-03 09:33:32.869] fTempGUIDMap: removing 0 items
# [2011-03-03 09:33:32.869] fTempGUIDMap: removing 0 items
# [2011-03-03 09:33:32.869] fTempGUIDMap: removing 0 items
# [2011-03-03 09:33:32.869] fTempGUIDMap: removing 0 items
# [2011-03-03 09:33:32.869] fTempGUIDMap: removing 0 items
# [2011-03-03 09:33:32.869] fTempGUIDMap: removing 0 items
# [2011-03-03 09:33:32.869] fTempGUIDMap: removing 0 items
# [2011-03-03 09:33:32.869] fTempGUIDMap: removing 0 items
# [2011-03-03 09:33:32.870] fTempGUIDMap: removing 0 items
# [2011-03-03 09:33:32.870] fTempGUIDMap: removing 0 items
# [2011-03-03 09:33:32.870] fTempGUIDMap: removing 0 items
# [2011-03-03 09:33:32.870] fTempGUIDMap: removing 0 items
# [2011-03-03 09:33:32.870] fTempGUIDMap: removing 0 items
# [2011-03-03 09:33:32.870] fTempGUIDMap: removing 0 items
# [2011-03-03 09:33:32.870] fTempGUIDMap: removing 0 items
# [2011-03-03 09:33:32.870] fTempGUIDMap: removing 0 items
# [2011-03-03 09:33:32.870] fTempGUIDMap: removing 0 items
# [2011-03-03 09:33:32.870] fTempGUIDMap: removing 0 items
# [2011-03-03 09:33:32.870] Never received status for command 'SyncHdr',
(outgoing MsgID=12, CmdID=0)
# [2011-03-03 09:33:32.870] Deleted command 'SyncHdr' (outgoing
MsgID=12, CmdID=0)
# [2011-03-03 09:33:32.870] fTempGUIDMap: removing 0 items
# [2011-03-03 09:33:32.870] fTempGUIDMap: removing 0 items
# [2011-03-03 09:33:32.870] fTempGUIDMap: removing 0 items
# [2011-03-03 09:33:32.870] fTempGUIDMap: removing 0 items
# [2011-03-03 09:33:32.870] Session data transfer statistics: incoming
bytes=84183, outgoing bytes=10697
# [2011-03-03 09:33:32.870] TSyncAgent::~TSyncAgent: Deleted SyncML
session (local session id=2965903147870997871)
# [2011-03-03 09:33:32.870] --------- END of embedded log for session ID
'2965903147870997871' ---------
9 years, 5 months
[SyncEvolution] Error when syncing a particular event
by Tino Keitel
Hi,
I have this error with syncevoltion 1.1.1a:
$ syncevolution eazy
[INFO] memo: inactive
[INFO] todo: inactive
[INFO] calendar: starting normal sync, two-way
[INFO] addressbook: starting normal sync, two-way
Local data changes to be applied remotely during synchronization:
*** calendar ***
no changes
*** addressbook ***
no changes
[INFO] calendar: started
[ERROR] calendar: retrieving item: -rid: Cannot retrieve calendar
object path: Object not found
[INFO] deleting <>
[INFO] calendar: received 1/2
[INFO] calendar: added 0, updated 0, removed 1
[INFO] adding "XXX anrufen"
[INFO] calendar: received 2/2
[INFO] calendar: added 1, updated 0, removed 1
[INFO] addressbook: started
[INFO] calendar: normal sync done successfully
[INFO] addressbook: normal sync done successfully
Synchronization successful.
Changes applied during synchronization:
+---------------|-----------------------|-----------------------|-CON-+
| | LOCAL | REMOTE | FLI |
| Source | NEW | MOD | DEL | ERR | NEW | MOD | DEL | ERR | CTS |
+---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+
| addressbook | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| two-way, 0 KB sent by client, 0 KB received |
| item(s) in database backup: 121 before sync, 121 after it |
+---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+
| calendar | 1 | 0 | 1 | 0 | 0 | 0 | 0 | 0 | 0 |
| two-way, 0 KB sent by client, 0 KB received |
| item(s) in database backup: 253 before sync, 253 after it |
+---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+
| start Wed Mar 9 16:14:25 2011, duration 0:12min |
| synchronization completed successfully |
+---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+
First ERROR encountered: calendar: retrieving item: -rid: Cannot
retrieve calendar object path: Object not found
Data modified locally during synchronization:
*** calendar ***
before sync | after sync
removed during sync <
> added during sync
-------------------------------------------------------------------------------
BEGIN:VCALENDAR BEGIN:VCALENDAR
VERSION:2.0 VERSION:2.0
BEGIN:VEVENT BEGIN:VEVENT
SUMMARY:XXX anrufen SUMMARY:XXX anrufen
DESCRIPTION:XXX anrufen DESCRIPTION:XXX anrufen
DTEND:20110112T160300Z DTEND:20110112T160300Z
DTSTART:20110112T150300Z DTSTART:20110112T150300Z
PRIORITY:5 PRIORITY:5
SEQUENCE:0 SEQUENCE:0
UID:UGCxv3FN4F2XY53HQF3rm0 UID:UGCxv3FN4F2XY53HQF3rm0
BEGIN:VALARM BEGIN:VALARM
ACTION:DISPLAY ACTION:DISPLAY
TRIGGER;VALUE=DATE-TIME:20110112T
TRIGGER;VALUE=DATE-TIME:20110112T
150300Z 150300Z
X-EVOLUTION-ALARM-UID:20110309T14 |
X-EVOLUTION-ALARM-UID:20110118T06
1831Z-2668-1001-1-84@mac | 5301Z-1807-1000-1-38@x61
END:VALARM END:VALARM
END:VEVENT END:VEVENT
END:VCALENDAR END:VCALENDAR
-------------------------------------------------------------------------------
*** addressbook ***
no changes
Regards,
Tino
9 years, 5 months