[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.
11 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.
11 years, 6 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.
11 years, 6 months
[SyncEvolution] Issues with evolution 2.32 and syncevolution 1.1.1a
by Tino Keitel
Hi,
I upgraded to evolution and EDS 2.32. My syncevolution does not work
anymore:
[INFO] memo: inactive
[INFO] todo: inactive
[ERROR] Error allocating calendar
I found this in the log file:
[2011-02-15 21:31:52.533] Error allocating calendar
[2011-02-15 21:31:52.533] (syncevolution:24341): libecal-WARNING **: Cannot get cal from factory: Invalid source
I tried to rebuild 1.1.1a against 2.32, which failed:
backends/evolution/.libs/syncebook.a(syncebook_la-EvolutionContactSource.o):
In function
`SyncEvo::EvolutionContactSource::removeItem(std::basic_string<char,
std::char_traits<char>, std::allocator<char> > const&)':
/tmp/buildd/syncevolution-1.1.1/src/backends/evolution/EvolutionContactSource.cpp:350:
/undefined reference to `e_book_remove_contact'
...followed by a lot of similar errors.
Regards,
Tino
11 years, 7 months
[SyncEvolution] CalDAV/CardDAV backends available
by Patrick Ohly
Hello!
I am happy to report that the mysterious new backend that I alluded to
earlier is now available as source code: src/backends/webdav in the
"master" branch of SyncEvolution provides access to CalDAV and CardDAV
servers.
Together with the work on "local sync" (already discussed on the list
and public all the time) this allows synchronizing calendars or address
books accessible to SyncEvolution (Evolution, directory with files, ...)
with servers like Google or Yahoo. Devices without support for
CalDAV/CardDAV can be synchronized with local files (file backend in
SyncEvolution) and then these files can be synchronized with a CalDAV or
CardDAV server.
The CalDAV/CardDAV work was originally done for the Intel MeeGo Tablet
UX shown at Mobile World Congress. When used in MeeGo, synchronization
is done in a Buteo sync plugin which comes with XML configurations for
Yahoo (calendar and addressbook, the latter not enabled) and Google
(calendar only). The plugin configures and invokes SyncEvolution. Source
is in src/backends/buteo.
The goal always was to release as open source, only the exact time was
uncertain. What I pushed to the public git repo is the full development
history, rebased onto the current master. It is unlikely that the
intermediate versions all compile, but the history is worthwhile to have
nevertheless.
The src/backends/webdav/README (attached) contains setup instructions,
debug hints and an overview of the implementation. There are no binaries
available yet; compile from source or wait for SyncEvolution 1.1.99.3.
Google Calendar works reasonably well, despite quite a few quirks in the
server that SyncEvolution has to work around. Yahoo Calendar worked a
lot better. On the other hand, Yahoo's CardDAV implementation is barely
usable. SyncEvolution has not been tested with anything else yet.
There's quite a bit of work left to do:
* CardDAVSource does not provide summaries for items (affects
--print-items)
* support multiple collections
* test with additional servers
* verify the DNS SRV/.well-known service discovery with a server
which supports both
* preserve vCard/iCalendar extensions on the servers
* get rid of the "source-config": would allow using CalDAV/CardDAV
as normal sources inside a SyncML session (direct sync with
phone or HTTP server)
* need some way how synchronization can be configured via the UI
* avoid race conditions, either with locking or ETags
If anyone wants to help, please let me know and I'll provide further
information about what would have to be done. Otherwise I'll tackle
these issues as time permits.
--
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, 7 months
[SyncEvolution] packagers: enable CalDAV/CardDAV in >= 1.1.99.3
by Patrick Ohly
Hello SyncEvolution packagers!
I've just released 1.1.99.3, which adds a CalDAV/CardDAV backend. Please
consider enabling it in your distros' builds. Here are some notes (from
README.packagers in git repo):
- use --enable-dav
- needs libneon[-gnutls] (use gnutls version, if available,
but make sure that it is >= 0.29.5, which has this patch:
http://lists.manyfish.co.uk/pipermail/neon/2010-November/001294.html)
- ensure that one of the following commands is available at runtime:
adnshost, host, nslookup
1.1.99.3 is still experimental. There is one user who reported an issue
with config migration that I couldn't reproduce, so I am reluctant to
recommend the 1.2 pre-releases for a wider audience.
--
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, 7 months
[SyncEvolution] N900 - Mozilla Lightning / Sunbird Support via Bluetooth?
by Jonathan Pritchard
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hello,
This project looks very interesting, and hopefully what I'm looking for.
I was wondering if there is a way to synchronise calendar data
primarily, from an N900 over Bluetooth to a Linux desktop running
Mozilla Lightning or Sunbird?
On my old Nokia phone, an N82, I used OpenSync to achieve this, but even
then it strictly only supports Mozilla Sunbird and not Mozilla
Lightning, in my experience.
Thanks, I'd appreciate the help.
Jon Pritchard
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAk1l+50ACgkQV/z7jdey4lGuVgCfcGFNOdgik1TpRSrKx+k75qX7
snYAnAjKhLfyynQ91MsvWBLc1d7gLwP8
=yCP/
-----END PGP SIGNATURE-----
11 years, 7 months
