[SyncEvolution] SyncEvolution ruby gem
by Emiliano Heyns
As part of my grappling with SyncEvolution, I've written a little script
that (a.o.) visualizes the current configuration, or dumps the current
configuration as a series of shell statements.
FOR THE LOVE OF ALL THAT'S HOLY, DO NOT BLINDLY EXECUTE THE RESULTING
SHELL CODE. ALPHA!
It can be installed by calling 'gem install syncevolution', after which
you can call either 'se-config --shell' or 'se-config --graphviz'
Emile
6 years, 6 months
Re: [SyncEvolution] Getting the concepts clear (Was: Configuring a target)
by Patrick Ohly
[adding the list back - Emile, please remember to do a group-reply]
On Wed, 2014-04-09 at 19:46 +0200, Emiliano Heyns wrote:
> On Apr 9, 2014 5:52 PM, "Patrick Ohly" <patrick.ohly(a)intel.com> wrote:
>
> > > So the target-config is considered to live inside the data source?
> >
> > Not inside the data source. It's treated like a sync config and thus
> > lives inside a context. Like a normal sync config it is connected to
> > data source configs via that context.
>
> So target configs can potentially be applied to any data source with
> which it shares a context.
There is only one "target-config" per context, because the name is
(currently) fixed. As discussed with Graham, this limitation could be
removed in favor of letting users choose their own target config name
with syncURL=local://<target config>@<context.
> > > And if the
> > > target-config hosts the sync property, it's also (in addition to
> being a
> > > kind of sync config) a kind of source config it seems. Which
> properties
> > > can a target-config hold?
> >
> > A target-config is exactly like a sync config and can hold all of
> the
> > sync properties. Whether all of them are useful or valid is a
> different
> > question. It's the usage that determines the difference between a
> sync
> > and a target config.
>
> But it can apparently also hold a property named 'sync', and that's
> listed as a source property. I'm confused now about what happens when
> you set the 'sync' property. Is the target-config changed? Then 'sync'
> appears to be a sync property. Is the source config changed? Then
> what's the role of the sync config being passed on the command line?
> The wording seems to imply something happens to the target-config when
> setting the 'sync' property, but that conflicts with how you spoke
> about what sync and source configs can hold.
The "sync" property is a per-peer source property. It defines how a data
source is used by a specific peer. Therefore it makes no sense to
"--configure sync=two-way @default addressbook", because there is no
peer mentioned anywhere and this "sync" value cannot be stored. The
"addressbook" source config referenced here only has the shared source
properties, which do not include "sync".
The "sync" property is primarily a source property, because in contrast
to sync properties there are multiple values for it, one for each
source. You can also think of it as the "sync" aspect of a data source,
when describing the role of a source in a sync.
Following that logic, the "--configure sync=two-way memotoo@default
addressbook" operation becomes valid and sets the "sync" property of
"addressbook" for syncing with memotoo.
Perhaps this becomes clearer when you look at the config.ini files
created under ~/.config/syncevolution. This shows you all existing sets
of config properties (source vs. sync, per-peer vs. shared).
The original config mechanism didn't have shared properties or contexts.
This made it impossible to define a source independently of a sync
config for a peer. This was replaced with today's system without
changing the command line. The command line creates a flat view of all
relevant properties (when printing a config) and updates the relevant
config.ini file for each property (when modifying).
This is a two-edged sword. Users who only have one sync config can
configure it as easily as before, without having to deal with multiple
different invocations for the different entities involved. But anyone
trying to do advanced things (and local sync with multiple different
databases is advanced) needs to understand the underlying logic, or
follow recipes.
Ideally this complexity would be hidden by some kind of UI with a setup
wizard. But no-one has volunteered to write that for desktop Linux or
even update the existing GTK UI, so desktop users are stuck with the
command line.
> > > If I were two sync two paired sources, that would allow for 4
> places
> > > where a sync property could be set then? What are sensible
> combinations?
> >
> > In a local sync, sync properties can be set in two places: on the
> side
> > used to trigger the sync (called "local" in the sync output) and the
> > target side (called "remote").
>
> I'm talking specifically about the property called 'sync'. Does it
> live in the data source (which was my first guess as it is listed as a
> source property) or in the target/sync config? Or both? And what is
> the expected behavior if two sides of a sync specify different values
> for the 'sync' property?
On the target side of a local sync the "sync" property is ignored. The
sync side chooses the sync mode and enables the corresponding target
sources automatically, without the user having to set their "sync"
property.
--
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.
6 years, 6 months
Re: [SyncEvolution] Getting the concepts clear (Was: Configuring a target)
by Patrick Ohly
On Wed, 2014-04-09 at 07:27 +0000, Emiliano Heyns wrote:
> On 09/04/2014 08:48:27, "Patrick Ohly" <patrick.ohly(a)intel.com> wrote:
>
> >> >> So a "peer" isn't really a SE concept, then?
> >> >SyncEvolution did not invent the term, yes. It gets defined anyway,
> >>to
> >> >make it clear in which meaning it is used.
> >> OK, then my howto is going to drop the work 'peer' too.
> >
> >Again, I suspect that avoiding the word will not be easy. Sometimes you
> >just have to give that thingie a name that you synchronize with, and
> >always saying "the server, phone, or other computer" gets tiresome.
> This is easier to avoid (so far) in my HOWTO -- the thingie simply gets
> a very concrete name.
Yes, for a specific HOWTO that's easy. It gets harder when talking about
the abstract concepts.
> >> Right! So use determines whether it is a sync or a source config! A
> >> config in and of itself is just a bag of properties!
> >
> >Wait, I was talking about sync and target configs above. You are right,
> >a "config" is just a set of properties, but there is a difference
> >between "source config" and "sync/target config" that goes beyond just
> >differnt usage, because there are two different set of properties that
> >can go into the former (--source-property ?) and the latter
> >(--sync-property ?).
> >
> >This difference is enforced when setting properties. You cannot set a
> >sync property in a source config or vice versa.
> Ah damn, I just thought I had a handle on things. So does SE determine
> whether you intend to configure a sync or a source config by looking at
> which properties you pass on the command line?
I explained that in my email to Khurshid (attached again). The key point
is that "--configure" modifies *everything* mentioned on the command
line. It's not configuring either sync or source config. Instead it does
both at the same time.
The main motivation is that (in most cases) it allows giving users a
single command which does everything necessary to set up syncing. The
exception is local sync, where one needs at least two commands. Whether
that flexibility is useful and/or necessary is up for debate. As Graham
said, he doesn't use the "<source name>/<property name>" syntax and
prefers to configure different sources with different commands.
> That would imply that
> 1. There is no property name that occurs both in --source-property and
> --sync-property (I looked and that seems true, but it would be good to
> know this is structurally true, not just incidentally), and
If there was an overlap, one could use --source-property or
--sync-property to disambiguate the meaning of an assignment on the
command line.
But because such an overlap would be confusing, it was avoided
intentionally.
> 2. No configure command can mix source and sync properties.
It can.
> In the synopsys, target-config is being explained in terms of being a
> special kind of sync config, But when configuring it, I can pass it a
> sync= parameter, where the sync property is a source property, not a
> sync property. How should I see this?
The "sync" property will get set for "target-config" in the sources
named together with the target-config. If no such source gets mentioned,
the "sync" property has no effect.
> >> > Sorry; I meant to say "is this why I repeat the credentials in the
> >> >setup
> >> >> of the datasource and of the sync config"?
> >> >Repeating the Google credentials in the target-config is not
> >>necessary
> >> >if they were already set as databaseUser/Password for the individual
> >> >source(s).
> >> And visa versa? If I define them in the target-config, can I omit
> >>them
> >> for the source configs?
> >
> >Yes. That was the original purpose of the "target-config": having a
> >place to store credentials.
> And we have target-configs attached to data sources because a data
> source might be accessed with differing credentials. Correct?
I don't follow here.
The credentials in the target-config are useful if (and only if) you
have multiple sources in the same context as that target-config which
share the same pair of username/password values. It was meant to avoid
duplication of information.
Nowadays I think it would be easier to avoid that feature in favor of
databaseUser=id:<config name> and storing username/password in that
config. That mechanism is newish (introduced in 1.4) and not documented
well enough at the moment, though.
6 years, 6 months
[SyncEvolution] SyncEvolution 1.4.1 released
by Patrick Ohly
About SyncEvolution
===================
SyncEvolution synchronizes personal information management (PIM) data
via various protocols (SyncML, CalDAV/CardDAV, ActiveSync). It syncs
contacts, appointments, tasks and memos. It syncs to web services or to
SyncML-capable phones via Bluetooth.
Binaries are available for Linux desktops (using GNOME Evolution, or
KDE's Akonadi), for Maemo (Nokia N900, N9) and Sailfish OS (Jolla
phone).
About 1.4
=========
The first bug fix release in the 1.4 series addresses some issues which
occurred on some systems. Several issues with Akonadi were fixed.
Details:
* EDS: only load one backend plugin of each kind
SyncEvolution was meant to load the syncecal or syncebook shared object
which uses the most recent libraries (libical, libecal/libebook) on
the system and then stop loooking for alternatives. Due to a string
handling bug the check for already backends always found nothing,
leading to multiple conflicting backends loaded on some systems (for
example, those with libical0 and libical1 installed).
If that happened, the backend became unusable.
* ical: workaround for libical 1.0 builtin timezone change
libical 1.0 started to return VTIMEZONE definitions with multiple
absolute transition times instead of RRULEs. This causes problems when
exchanging data with peers (see
https://sourceforge.net/p/freeassociation/bugs/95/).
In SyncEvolution, this affected sending an event using New Zealand
time in vCalendar 1.0 format to a phone, because the internal,
out-dated definition of the time zone in libsynthesis was used as
fallback when loading RRULE-based timezone definitions from libical
failed (see "[SyncEvolution] Some events showing wrong time on
phone"). It might also affect exchanging data with CalDAV peers (not
tested).
The workaround is to include the original code from libical.
* dbus-session.sh: create XDG_RUNTIME_DIR
More recent distros (for example, Ubuntu Saucy) rely on
XDG_RUNTIME_DIR. Each time dbus-session.sh runs, it must
ensure that the runtime dir exists and is empty.
This was a problem when trying to run activesyncd + SyncEvolution
on a headless Ubuntu Saucy server (see FDO #76273).
* Akonadi: support KDE Notes, enhanced "database" check
The KDE Notes resources store items under a different MIME type than the one
used in AKonadi (see "[Kde-pim] note format"). SyncEvolution use the same type
as Akonadi and thus did not find existing KDE Notes resources.
To support both while KDE and Akonadi transition to the same type,
SyncEvolution now looks for notes resources using both MIME types and accepts
both kinds of items when reading. When writing, SyncEvolution picks the MIME
type that is supported by the resource, which hopefully avoids confusing the
KDE app using the resource (untested).
As a positive side effect, the "database" value used for opening a resource is
now checked more thoroughly. Non-existent resources and the type mismatches
like pointing a "kde-contacts" backend to a calendar resource are now detected
early.
* Akonadi: ensure that UID is set (FDO #74342)
Akonadi resources do not enforce iCalendar 2.0 semantic like
"each VEVENT must have a UID" (see "[Kde-pim] iCalendar semantic").
When receiving an event from a peer which itself does not enforce
that semantic (Funambol, vCalendar 1.0 based phones), then we
need to generate a UID, otherwise KOrganizer will ignore the
imported event.
* Akonadi: avoid threading problem in HTTP server mode (FDO #75672)
When used as storage in a server, Akonadi got called in a background thread
that gets created to handle slow initialization of sources and preventing
ensuing timeouts in HTTP clients (probably not needed for Akonadi itself,
but may still be useful when combining it with other sources).
Akonadi cannot be used like that, leading to false "Akonadi not running"
errors or (if one got past that check) failing item operations.
* autotools: Add QtCore include path to KDEPIM_CFLAGS (FDO #75670)
This fixes an issue where configure fails to find Akonadi when
test programs do not compile because QString is not found.
* Enhanced testing again: faster execution, less false negatives
under load. Re-enabled testing of Akonadi.
Upgrading from releases <= 1.3.99.4:
------------------------------------
If the value of "username/databaseUser/proxyUser" contains a colon,
the "user:" prefix must be added to the value, to continue treating it
like a plain user name and not some reference to an unknown identity
provider (like "id:", "goa:", "signon:", etc.).
The lookup of passwords in GNOME Keyring was updated slightly in
1.3.99.5. It may be necessary to set passwords anew if the old one is
no longer found.
Upgrading from release 1.2.x:
-----------------------------
The sync format of existing configurations for Mobical (aka Everdroid)
must be updated manually, because the server has encoding problems when
using vCard 3.0 (now the default for Evolution contacts):
syncevolution --configure \
syncFormat=text/x-vcard \
mobical addressbook
The Funambol template explicitly enables usage of the
"refresh-from-server" sync mode to avoid getting throttled with 417
'retry later' errors. The same must be added to existing configs
manually:
syncevolution --configure \
enableRefreshSync=TRUE \
funambol
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. Releases >= 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/2014/syncevolution-141-released
Source code bundles for users are available in
http://downloads.syncevolution.org/syncevolution/sources
and the original source is in the git repositories
http://cgit.freedesktop.org/SyncEvolution/
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:
deb http://downloads.syncevolution.org/apt stable main
Then install "syncevolution-evolution", "syncevolution-kde" and/or
"syncevolution-activesync".
These binaries include the "sync-ui" GTK GUI and were compiled for
Ubuntu 10.04 LTS (Lucid), except for ActiveSync binaries which were
compiled for Debian Wheezy, Ubuntu Saucy and Ubuntu Trusty. The packages
mentioned above are meta-packages which pull in suitable packages
matching the distro during installation.
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/. 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
6 years, 6 months
Re: [SyncEvolution] merging of winning and loosing items
by Patrick Ohly
On Wed, 2014-04-09 at 12:55 +0000, Emiliano Heyns wrote:
> On 09/04/2014 14:49:22, "Patrick Ohly" <patrick.ohly(a)intel.com> wrote:
>
> >
> >It's hard to do with the existing Synthesis engine (it expects the data
> >stores to really apply changes) and protocols. SyncML has sync anchors
> >and could in theory repeat the last sync, but I suspect that many
> >implementations will not implement that correctly. libsynthesis does
> >(as
> >far as I know), but SyncEvolution doesn't.
> >
> How did Google's Wave and products like CouchDB handle such things? As
> they revolve around sync, this ought to be a huge problem for these.
These are closed systems and thus have full control over all sides of
the sync and the protocol involved. Therefore it is a different problem
whose solution wouldn't work for SyncEvolution.
For example, CouchDB assumes that a DB gets created in one place and
then gets replicated. You cannot take two independent DBs and merge them
(at least as far as I know - I am not a CouchDB expert). The data also
cannot be stored in a different format outside of the DB (in particular
using the existing PIM storage of a certain system).
See also
https://syncevolution.org/development/pim-data-synchronization-why-it-so-...
--
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.
6 years, 6 months
Re: [SyncEvolution] Correct incantation for sqlite backend
by Patrick Ohly
On Wed, 2014-04-09 at 07:31 +0000, Emiliano Heyns wrote:
> On 09/04/2014 08:30:42, "Patrick Ohly" <patrick.ohly(a)intel.com> wrote:
>
> >On Tue, 2014-04-08 at 19:46 +0000, Emiliano Heyns wrote:
> > Currently inactive::
> > XMLRPC interface = xmlrpc
> > Data exchange is done via an XMLRPC interface on the datastore.
> >
> Shame, I had plans for that. Ah well.
You would have to compile from source to use it. I could enable it in
syncevolution.org builds, but I am not certain how useful it would be.
> Is this the right incantation for caldav at Google?
>
> syncevolution --configure \
> backend=caldav \
> databaseUser=john.doe(a)googlemail.com \
> databasePassword=foobar \
>
> database=https://www.google.com/calendar/dav/%u/user/?SyncEvolution=Google
> \
> @google \
> main-google-calendar
Looks right for the default calendar. For other calendars it is
database=https://www.google.com:443/calendar/dav/<calendar
ID>/events/?SyncEvolution=Google.
--
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.
6 years, 6 months
[SyncEvolution] SSLVerifyHost and SSLVerifyServer for a Source
by Dustin Demuth
Hi,
(how) is it possible to configure the "SSLVerifyHost" and
"SSLVerifyServer" parameters for a Source?
I'd need this to sync my phone (peer) with a webdav (source).
Unfortunately the WebDAV-server certificate does not match it's hostname
right now.
Errors I receive right now:
[ERROR] transport problem: REPORT 'full calendar': Neon error code 1, no
HTTP status: Server certificate verification failed: certificate issued
for a different hostname
BR
Dustin
Some good thinks, I want to tell:
Syncevolution is a really good piece of software. Versatile, active
development, vibrant mailing list. I like it.
6 years, 6 months
Re: [SyncEvolution] Configuring a target
by Graham Cobb
Emile,
I have attempted to provide some explanations. Of course, like you, I
find the configuration structure difficult to understand so Patrick may
need to make corrections!
On 02/04/14 09:49, Emiliano Heyns wrote:
> I can now access the GCal database, but if I don't pass the credentials
> on the command line, it fails or hangs. Can I store these in gconf too?
> This is how I'm setting it up:
>
> OPTIONS=
> OPTIONS="${OPTIONS} password=${GOOGLE[password]}"
> OPTIONS="${OPTIONS}
> syncURL=https://www.google.com/calendar/dav/%u/user/?SyncEvolution=Google"
> OPTIONS="${OPTIONS}
> database=https://www.google.com/calendar/dav/${GOOGLE[calendar]}/events?S..."
SyncEvolution normally stores usernames and passwords itself.
ActiveSync is unusual in that it uses gconf and keyrings. So, for the
Google access, you need to give the usernames and passwords to
SyncEvolution.
> syncevolution --configure --template none backend=caldav
> username=${GOOGLE[email]} $OPTIONS target-config@Google
> And this is how I'm printing the DB:
>
> OPTIONS=
> OPTIONS="${OPTIONS} password=${GOOGLE[password]}"
> OPTIONS="${OPTIONS}
> database=https://www.google.com/calendar/dav/${GOOGLE[calendar]}/events?S..."
>
> syncevolution --print-databases username=${GOOGLE[email]} backend=caldav
> $OPTIONS
--print-databases is standalone -- it doesn't use (or need) any configs
set up. That is why you have to inclue the username and password on the
actual command line itself to use --print-databases.
> Setting up the actual sync (exchange-local so far -- on to google once I
> understand this) is still mystifying. This is what works (for Exchange
> <-> Local), but I have no idea why:
Part of the confusion may be understanding the need for two sides to the
sync. Here is my best go at explaining what is going on.
Firstly, forget about the actual task we are trying to do: think about a
traditional sync done by SyncEvolution. In that case, SyncEvolution is
syncing a local database (files, Evolution, KDE, whatever) with some
remote device (mobile phone, etc). In that case, you set up two, related
pieces of information: a "source config" (for example @Local), which
defines the local database you are trying to sync (and what folders it
contains -- known as sources), and a "sync config" (for example
MyPhone@Local) which defines how SyncEvolution communicates with the
peer, which actual folders should be synced to this particular peer,
what sorts of syncs should be done, etc.
If you have multiple phones, you might set up multiple sync configs for
the same source config -- each one tells SynceEvolution how to handle
syncing with that particular device peer (for example, you might sync
different source folders with different devices).
This works fine if the remote device is a SyncML device, such as a
phone. But it also works if the remote device is another instance of
SyncEvolution running on a different host. In this case, you would set
up another similar configuration on the other host (maybe you would
create a source config on that other host called @OtherHostFiles, and a
sync config on that other host called FirstHost@OtherHostFiles). Of
course, you would set up the sync configs involved (one on the first
host, the other on the other host) so that they would talk to each other
(one would make the connection, the other would receive it).
Now make the scenario a little more complex again. One or other or both
of the sources involved could be Exchange or Google or Webdav and might
not be physically located on either the first host or the other host.
So, using this, you could set up a sync which runs on FirstHost, and
accesses an Exchange source on ExchangeHost instead of local files. Or
maybe the source on OtherHost would be a Google database, on GoogleHost
instead of local files.
In any of these cases, we have two separate source configs (one on
FirstHost called @Local, and one on OtherHost called @OtherHostFiles),
one sync config set up for each source config: OtherHost@Local on
FirstHost and FirstHost@OtherHostFiles on OtherHost. In each case, the
source databases have to be defined and the peer information has to be
defined on each one to know how to connect to the other (whether to make
a conection or wait for an incoming connection, which source folders to
expose to the other end, whether to print changes during the sync, etc).
I think this is reasonably logical -- each host needs to know how it
should talk to the other host.
The confusion comes when both sides actually run on the same host, in
the same SyncEvolution instance. That is what we are doing in your
Exchange<->Local sync example. In this case, SyncEvolution optimizes
away some of the actual connection details but it doesn't optimize away
any of the source or sync configs. That is why you end up having to
create a source config for the local files (@Local) and a sync config to
tell it what to sync with (Exchange@Local) and also a source config for
the Exchange server (@Exchange) and a sync config to tell it what to
sync with (target-config@Exchange). The reason the latter has to be
called "target-config" is to do with the optimisations SyncEvolution is
doing to avoid having an actual SyncML TCP connection between the two
sides. It is for the same reason that in Exchange@Local you have to
setup a URL as the form local://.
[By the way, Patrick, I think things would be easier to understand if it
was possible to setup the local syncUrl as "local:://peer@source" and
"peer@source" would be the corresponding sync config instead of the
special name target-config@source. It may be there is some reason not
to do that, but I have always thought of target-config as a horrible hack]
That was probably far too long, but having written it, here are my
answers to your remaining questions...
>
> # TODO: I thought "syncevolution --configure" set up a peer... is the
> x@y automatically a sync config between peers? Does this set up all
> possible (cal-cal, contact-contact) pairings?
> syncevolution --configure --template none username= password=
> printChanges=1 Exchange@Local
--configure sets up either a source or a sync (peer) config, depending
on whether there is peer name before the @. In this case, it is setting
up a sync config (for a peer). This defaults to setting up the details
for all sources (folders) within the named source, so it is telling
SyncEvcolution that it will expose all folders defined in the @Local
source when you use the Exchange@Local sync config.
> # TODO: Seems to be necessary but I don't know what it does.
> syncevolution --configure syncUrl=local://@Exchange peerIsClient=1
> Exchange@Local
This could have been combined with the previous command. It is
providing more details for how SyncEvolution should communicate with the
peer when you use the Exchange@Local sync config.
The most important detail it is providing is how to contact the remote
side of the sync (the OtherHost, in my explanation above). In this
case, it is saying "use the local optimisations -- the remote side of
this sync is on the same host and uses a sync called
target-config@Exchange). Note that the text "Exchange" in the two
places it appears in this command are completely unrelated. They could
be replaced with Foo and Bar and everything would still work (as long as
they were replaced in the other comamnds as well, of course).
> # TODO -- what is the meaning of 'uri=contacts' here? The docs say "is
> added to the end of the server URL". Is this then the actual sync setup
> between contacts-exchange and contacts-local?
> syncevolution --configure sync=two-way uri=contacts Exchange@Local
> contacts
> syncevolution --configure sync=two-way uri=calendar Exchange@Local
> calendar
Here you are setting more details of how to contact the other side of
the sync. However, these details are actually different for the
different folders (in the earlier commands, the details applied to all
folders/sources that are part of the source).
"uri" is used to set the name that the other side uses for this folder.
So, for example, you might have a contacts folder called "business" and
one called "personal". Assume you have two phones (one personal, one
business) and each phone can only sync with one contacts database, and
expects that database to be called "contacts". When syncing with your
personal phone, you might use "syncevolution --configure uri=contacts
MyPhone@Local personal" and for your work phone you might use
"syncevolution --configure uri=contacts WorkPhone@Local business". In
other words, in some syncs you expose "personal" as if it was called
"contacts", in others you expose "business" as if it was called "contacts".
In most cases, the uri should be the same as the source name.
The sync= option is used to define whether that particular source folder
should actually be synced at all (in that sync config). If you decide
that you don't want to sync that folder at all, use sync=none. I have
no idea if other values for that option are meaningful.
> # TODO -- why are we setting up two-way sync here again? Isn't this
> part of the peer setup I did earlier?
> syncevolution --configure --template none username=${EXCHANGE[email]}
> password= printChanges=1 target-config@Exchange
Now we get to the other side of the sync. The earlier commands set up
the @Local side of the sync -- the side to do with the local database.
Now we set up the details for the other end of the sync, the part which
runs on OtherHost in my explanation (except that it is actually on the
same host). Maybe this does duplicate some information we have already
configured on the other side but the SyncEvolution local optimisations
don't detect that. This is treated as almost separate (the only link
between the two configs is the syncUrl=local:... set up earlier).
>
> # TODO -- What is the meaning of the last contacts/calendar in these
> lines? Shouldn't this be part of the peer setup rather than the sync setup?
> syncevolution --configure sync=two-way uri=contacts
> target-config@Exchange contacts
> syncevolution --configure sync=two-way uri=calendar
> target-config@Exchange calendar
You are setting up the peer information for the @Exchange side of the
sync. Telling it about how to do the sync with the other side (the
@Local side in this case). In this case you are specifying that the
Exchange source "calendar" should be exposed to the other side as
"calendar" (seems sensible).
I hope that has helped a little, not just made things more confusing.
Now Patrick can correct it!
Graham
6 years, 6 months
[SyncEvolution] Correct incantation for sqlite backend
by Emiliano Heyns
Hi,
I'm trying to set up a sqlite source config, using
syncevolution --configure --template none backend=sqlite
database=file:///home/eas/local/contacts.sqlite @Local contacts
When I do this, I get:
[INFO] contacts: looking for databases...
[INFO] contacts: backend failed: error code from SyncEvolution fatal
error (local, status 10500): contacts: inactive
[ERROR] error code from SyncEvolution fatal error (local, status 10500):
contacts: inactive
Is the sqlite backend not active in 1:1.4.1-2?
Thanks,
Emile
6 years, 6 months
[SyncEvolution] syncevolution.org site + Wiki: write access disabled
by Patrick Ohly
Hello!
Spam has been an on-going issue with comments and the Wiki on
syncevolution.org; some spammers must have found a way around the
captcha mechanism for registering users or a hole in the Drupal
installation.
It became worse again recently. I cleaned up last week, but over the
weekend another 50 fake users were registered and several hundreds of
fake new Wiki pages created. This showed up in the site feed.
I'm therefore revoking all write access to the site for normal users. I
would have liked to avoid that because some users found the comments
useful (*), but I have neither time nor motivation to maintain that
aspect of SyncEvolution.
Besides the comment system, the site would also need some serious work
on updating the content and perhaps pruning some of the old, obsolete
comments and pages. There's also the risk that Intel will stop
supporting the separate SyncEvolution site and expect some of the
content to move 01.org, Intel's central site for open source projects.
I'm not sure how download.syncevolution.org would work in such a case.
If there is someone around who wants to host the site and/or become
administrator, please speak up. The site content is stored in Drupal,
with a file system directory exposed as download.syncevolution.org.
(*) On the other hand, some of the comments were bug reports or general
requests for help, which probably would have been better handled via
this list or the bug tracker.
--
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.
6 years, 6 months
