[SyncEvolution] bridgie syncml server and caldav/card dav server
by Robert Schetterer
Hi, is there a chance to use syncevolution
as a bridge between a syncml server and a caldav/carddav server and vice
versa
i.e horde or funambol server syncml and DAViCal etc
--
Best Regards
MfG Robert Schetterer
Germany/Munich/Bavaria
9 years, 6 months
[SyncEvolution] Syncevolution build system conversion
by Krzesimir Nowak
Hi.
My name is Krzesimir Nowak. I work for Openismus GmbH who asked me to
try to convert Syncevolution's build system to a (simpler) non-recursive
Automake build. I now have something that works, with no obvious
regressions.
I've been working in a remote branch (I branched from Chris Kuehl's
dbus-server-reorganization because that already has some improvements
and it looks like it will get into master first).
https://meego.gitorious.org/~krnowak/meego-middleware/syncevo-autotools-c...
but I have also attached it as one patch, which might be easier to
review.
This should be simpler and more robust (for instance, against weird
linker problems), with less duplication, and it allows faster builds via
make -j.
It also removes the pre/post configure system and the *-gen.am system
which can be unfamiliar to regular users of autotools.
Patrick's minimum requirement was to still have the version number
autogenerated from the git version, and I have managed to keep that.
Patrick also preferred not having to list all the templates and config
files, but I have only partly achieved that.
I think it would be wise to make further step-by-step improvements once
this first step is in master. For instance, see:
https://meego.gitorious.org/~krnowak/meego-middleware/syncevo-autotools-c...
Regards,
Krzesimir
9 years, 9 months
[SyncEvolution] Online contacts in Harmattan
by Ove Kåven
While I'm at it, someone told me that on the N950 (Harmattan), when he
was logged onto Facebook, SyncEvolution would try to include his entire
Facebook friend list in the sync, which is unfortunate.
Before I spend too much time looking into it myself (I don't have much
of it, after all), do you know an obvious way in QtContacts to suppress
such online contacts, so that only contacts that are actually stored in
the device's own database would be synced?
9 years, 11 months
[SyncEvolution] ActiveSync contact support
by Patrick Ohly
Hello!
I'm currently looking at the eas<->vCard 3.0 conversion in activesyncd.
It is partly broken (one cannot do strcpy of the BDAY value between the
two, the format is different; EMAIL without attribute was ignored).
That's easy enough to fix, but there's a more fundamental issue.
ActiveSync has a fixed data model, which in the case of contacts only
supports:
* three different email addresses (without a way to mark them as
work/home/other)
* two postal addresses (one work, one home)
* ten different phone numbers:
* two business voice
* two home voice
* one business fax
* one business fax
* one cell
* one car
* one radio (whatever that means nowadays)
* one pager
This is a subset of what vCard supports. Conversion to vCard is possible
without data loss.
The challenge now is: should the vCard to EAS conversion try to be smart
and preserve as much data as possible, or should it set what it can and
ignore the rest?
For email, the current approach is to fill the three slots with the
first three EMAIL properties. There's not much that can be done
differently.
For postal addresses it becomes more interesting: if a vCard has two
WORK ADR, should one be stored as business and the other as home
address? At least it would be stored, albeit with the wrong type.
Same for things like cell phone. I'm certain that some of my address
book entries have more than one TEL with TYPE=CELL.
Right now I am leaning towards keeping activesyncd simple. Let it store
vCards that match the EAS data model, but don't worry about those who
don't.
That pushes the problem towards SyncEvolution. It doesn't make it easier
to solve, but that's where the solution conceptually belongs.
On the other hand, SyncEvolution doesn't really know about these
limitations of a specific ActiveSync server. I bet it does depend on the
specific ActiveSync protocol revision, which is not exposed to
SyncEvolution at the moment - at least not via the libeassync API.
I could rant now about the pros and cons of a fixed data model that is
specified as part of a synchronization protocol. There are advantages,
but only as long as you don't need anything that isn't included. With
Evolution<->Google synchronization via ActiveSync we'll have the
"ironic" situation that both sides support arbitrary number of phone
numbers, but they can't synchronize that against each other.
With ActiveSync, that is a limitation of the protocol. With SyncML, the
limitation is often in the implementation - not better in practice, but
at least it could be fixed :-/ For example, Google's SyncML
implementation doesn't support BDAY, although it could.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
10 years
[SyncEvolution] Recurrences in Maemo 5
by Ove Kåven
I've been looking into why, when I sync my trusty old N900 with Google
Calendar via CalDAV, the calendar shows "duplicate" events when I've
changed an instance of a recurrence in Google Calendar. (One event will
show with the old data, and one with the new data.)
Perhaps the answer would have been obvious if I knew the ical standard
better. It seems that when Google records a changed instance, they add
an event with the same global UID as the original one, and then uses
RECURRENCE-ID to identify the particular instance.
Since the Maemo 5 (Fremantle)'s calendar-backend does not store the
global UID, that was bound to fail. (And, as far as I call tell,
calendar-backend also only stores the RECURRENCE-ID if a RRULE is also
present in the same event, which it isn't - and even when it stores the
ID, it doesn't use it.)
It looks like this calendar-backend will only honor RDATEs and EXDATEs,
which must be stored in the original event (the one with the RRULE).
Then, I suppose, the changed instances would look like single events to it.
Is there any reasonable way SyncEvolution could do that conversion, so I
won't have to keep scratching my head trying to remember which was the
original, superseded event?
10 years
[SyncEvolution] SyncEvolution 1.1.99.7 released
by Patrick Ohly
SyncEvolution 1.1.99.6
======================
Mostly bug fixes again. Some are a bit more intrusive, thus another
pre-release.
* syncevolution.org binaries: now compatible with Debian Testing/libnotify.so.4 (BMC #22668)
libnotify is not linked directly into syncevo-dbus-server in the
syncevolution.org binaries. Instead libnotify.so.1 till .so.4
(current Debian Testing) are opened opened dynamically and the
necessary functions are looked up via dlsym(). Not finding the
libraries or the functions silently disables this notification
mechanism.
* calendar sync: better handling for add<->add conflicts (partly fixes BMC #22783)
When both sides of a sync have added the same event, the sync must
determine which one is more recent instead of blindly overwriting
always the same side. Such conflicts are typically rare except for
enterprise scenarios where meeting invitiations are processed
automatically by a groupware (Exchange, Google Calendar/Mail, ...)
and then the attendee status is updated on one side.
SyncEvolution now does the necessary age comparison and preserves the more
recent data for most properties. In some properties the data from both
sides is preserved by concatenating the text (description, location, ...).
It remains to be seen whether that is really desirable. Also, sync statistics
are slightly off: the incoming item is counted as "added" even though it
gets turned into an update.
* item operations: authentication problem for WebDAV when using keyring (BMC #21311)
The password still wasn't looked up in the keyring when using
--import/export/delete-items.
* "databasePassword" source property: lookup failure in keyring (BMC #22937)
The databasePassword also wasn't looked up at all when doing item operations
via the command line.
When configuring sources for an HTTP server, the config name typically
is just the context (@foo). When using the config in the HTTP server,
the config name is the peer inside that context (client@foo). Because
the GNOME keyring lookup keys for the "databasePassword" (more
specifically, the object name) contained the full config name which
was different in both cases, looking up the saved password failed.
The solution is to normalize the config name (to accomodate for
different ways of spelling it) and use only the context, with @ as
before. This will break existing setups where the object name in the
keyring (incorrectly) includes the full config name. In that case just
configure the source again to set the password anew.
* Evolution Calendar: fixed detached recurrence support (BMC #22940)
When manipulating a meeting series with more than one detached
recurrence certain sequences of operations could incorrectly fail
with "UID already exists".
* iCalendar 2.0: must set VALUE in EXDATE (part of BMC #22940)
EXDATE has a VALUE parameter, which wasn't defined in the XML
profile. Didn't seem to matter at all in practice, but wasn't
standard-compliant.
* GTK sync-ui: wrap sync service descriptions (BMC #7199)
Descriptions of different sync services are not fully visible unless
word-wrapping gets enabled.
* source configs: don't check "backend" unless it is needed
When using a config which has sources with a backend type set which is
not currently available, an error was thrown even if those sources
weren't even part of the current operation (for example, syncing
another source which is currently supported).
* config migration: avoid name conflicts and auto syncing of old configs (BMC #22691)
When (auto-)migrating a config, it was possible that a name for the
peer, say foo.old, was chosen for the renamed config although there
was already such a config, for example foo.old in ~/.sync4j. Besides
being confusing for users, this also led to a bug in the code where it
copied from the older config with the foo.old name.
The main problem fixed is the disabling of auto syncing
in the old config. Otherwise it was still used by syncevo-dbus-server
for syncing, which triggered another auto-migration, ad infinitum...
* auto syncing: must check whether enabled when looking at unknown URLs (part of BMC #22691)
"syncURL = insert your URL here" with "autoSync = 0" did lead to auto
sync attempts although it wasn't enabled. A check for "auto syncing
enabled" was missing for the "unknown transport" case.
* CalDAV/CardDAV + local storage: avoid empty properties
The main motivation for this change is that a recent Apple Calendar
server rejects vCards with empty BDAY property. Another reason is that
keeping the data as small as possible is desirable by itself.
Sending an empty property serves as a hint for the peer that the
property is supported. This is not necessary when storing an item in a
backend. Therefore this commit disables empty properties for all
backends which do not themselves set the m_backendRule Synthesis info
value.
* Apple CardDAV: apply PHOTO import/export scripts by default
A recent Apple Calendar server (correctly) rejects the invalid
PHOTO;TYPE=unknown: property in a vCard. This internal representation
must be cleared before serializing the field list.
* for developers: modified backend API
- ClientTestConfig modernized
- InsertItemResult::m_merged turned from boolean to enum
* testing and compilation changes; for example, the minimum version of
libsynthesis is now checked at configure time instead of failing at
runtime due to missing features in the Synthesis engine
Source, Installation, Further information
=========================================
http://syncevolution.org/blogs/pohly/2011/syncevolution-11997-released
Source snapshots are in
http://downloads.syncevolution.org/syncevolution/sources
i386, lpia amd64 binaries for Debian-based distributions are
available via the "unstable" syncevolution.org repository. Add the
following entry to your /apt/source.list, then install
"syncevolution-evolution":
deb http://downloads.syncevolution.org/apt unstable main
These binaries include the "sync-ui" GTK GUI and were compiled for
Ubuntu 8.04 LTS (Hardy). Older distributions like Debian 4.0 (Etch) can
no longer be supported with precompiled binaries because of missing
libraries, but the source still compiles when not enabling the GUI (the
default).
The same binaries are also available as .tar.gz and .rpm archives in
http://downloads.syncevolution.org/syncevolution/evolution. In contrast
to 0.8.x archives, the 1.x .tar.gz archives have to be unpacked and the
content must be moved to /usr, because several files would not be found
otherwise.
After installation, follow the
http://syncevolution.org/documentation/getting-started steps.
--
Patrick Ohly, on behalf of everyone who has helped
to make SyncEvolution possible:
http://syncevolution.org/about/contributors
10 years, 1 month
[SyncEvolution] releasing 1.2
by Patrick Ohly
Hello!
I'm currently integrating some more fixes into the 1.2 branch which were
not in 1.1.99.6 (add<->add conflict (BMC #22783), command line and
source passwords (BMC #21311, #22937), fixing some EDS API issues with
regards to multiple detached recurrences (BMC #22940), don't check
"backend" unless it is needed, backend API changes, updated testing).
More details once I have written an updated NEWS entry tomorrow.
I can either publish a 1.1.99.7 release candidate this Friday before
going on a 10 day vacation or call it 1.2 right away.
Are there opinions either way? Anyone willing to give a release
candidate some testing, in particular with an eye towards the more
recent changes? Anyone urgently waiting for the final 1.2?
--
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, 1 month
Re: [SyncEvolution] Multi-point sync
by Patrick Ohly
On Mi, 2011-09-07 at 17:48 -0400, Ross Vandegrift wrote:
> On Wed, 2011-09-07 at 08:23 +0200, Patrick Ohly wrote:
> > **Warning:** in local sync, the sync config side acts as
> > server. Therefore the ``from-server`` variants
> > (``one-way-from-server``, ``refresh-from-server``) transfer data
> > from the sync config into the target config. The ``from-client``
> > variants transfer in the other direction, even if the target config
> > happens to access data on a remote server.
> >
> > Hmm, it is not obvious that this also applies to syncing with devices
> > via Bluetooth.
> >
> > This issue came up before, but there was no conclusion about the naming.
> > Should it be "refresh/one-way-from-peer" and
> > "refresh-the-peer/one-way-to-peer"? "refresh/one-way-from-local" and
> > "refresh/one-way-to-local"?
>
> I don't totally know what would've been obvious here - I don't think I
> have a good enough handle on things to give good input.
Let me phrase the question differently: if the options for "--sync" aka
"--source-property sync" had been named as follows, would that have
avoided the problem?
$ syncevolution --sync ?
--sync
Requests a certain synchronization mode when initiating a sync:
two-way = only send/receive changes since last sync
slow = exchange all items
refresh-from-remote = discard all local items and replace with
the items on the peer
refresh-from-local = discard all items on the peer and replace
with the local items
one-way-from-remote = transmit changes from peer
one-way-from-local = transmit local changes
disabled (or none) = synchronization disabled
refresh/one-way-from-server/client are also supported. Their use is
discouraged because the direction of the data transfer depends
on the role of the local side (can be server or client), which is
not always obvious.
When accepting a sync session in a SyncML server (HTTP server), only
sources with sync != disabled are made available to the client,
which chooses the final sync mode based on its own configuration.
When accepting a sync session in a SyncML client (local sync with
the server contacting SyncEvolution on a device), the sync mode
specified in the client is typically overridden by the server.
> And even if that doc snippet doesn't clearly refer to bluetooth, I still
> didn't read it...
I know, this warning isn't the right way of solving the problem. From
which documentation did you learn about the available sync modes?
> > > After syncing with the laptop, going back to the desktop works, but
> > > forces a slow sync. Repeating this seems to indicate that it always
> > > needs to slow sync calendar+todo, even if there are no changes. Is this
> > > expected behavior?
> >
> > No. Does this only happen for calendar+todo, but not for addressbook?
>
> Hmm - I could reproduce this 100% last night, but not at all this
> afternoon. Syncs are normal when there's nothing to update, but I've
> run into another weird issue - data doesn't always sync through both
> "hops"
>
> Here's a case where I edit a contact on desktop, sync desktop<->phone,
Anchors from that sync:
[2011-09-07 17:33:55.029] Saved Last Remote Client Anchor='845', received <last> Remote Client Anchor='845' (must match for normal sync)
[2011-09-07 17:33:55.029] Received <next> Remote Client Anchor='845' (to be compared with <last> in NEXT session)
[2011-09-07 17:33:55.029] (Saved) Last Local Server Anchor='20110907T212942Z', (generated) Next Local Server Anchor='20110907T213355Z' (sent to client as <last>/<next> in <alert>)
> sync laptop<->phone. The edited Contact doesn't get sent to the laptop
> from the phone.
[2011-09-07 17:35:20.989] Saved Last Remote Client Anchor='847', received <last> Remote Client Anchor='847' (must match for normal sync)
[2011-09-07 17:35:20.989] Received <next> Remote Client Anchor='847' (to be compared with <last> in NEXT session)
[2011-09-07 17:35:20.989] (Saved) Last Local Server Anchor='20110907T213407Z', (generated) Next Local Server Anchor='20110907T213520Z' (sent to client as <last>/<next> in <alert>)
Why the phone doesn't send the contact is unknown. That's decided by the
phone itself.
> Then, I go back an sync on the desktop and it does a slow sync with no
> changes to either side.
[2011-09-07 17:35:35.325] Saved Last Remote Client Anchor='845', received <last> Remote Client Anchor='847' (must match for normal sync)
[2011-09-07 17:35:35.325] Received <next> Remote Client Anchor='847' (to be compared with <last> in NEXT session)
[2011-09-07 17:35:35.325] (Saved) Last Local Server Anchor='20110907T213355Z', (generated) Next Local Server Anchor='20110907T213535Z' (sent to client as <last>/<next> in <alert>)
[2011-09-07 17:35:35.325] (Saved) fResumeAlertCode = 0 (valid for >DS 1.2 only)
+–[2011-09-07 17:35:35.325] 'DSStateChange' - Datastore changes state, datastore=addressbook, oldstate=admin_ready, newstate=server_alerted [--][++] [->end] [->enclosing]
–[2011-09-07 17:35:35.325] End of 'DSStateChange' [->top] [->enclosing]
[2011-09-07 17:35:35.325] Alerted (code=200) for two-way Normal Sync
[2011-09-07 17:35:35.325] Switched to SlowSync because of Anchor mismatch or server-side user option
[2011-09-07 17:35:35.325] Created command 'Alert' (outgoing)
[2011-09-07 17:35:35.325] ALERTED from client for slow Sync
Note that the phone sent 845 as its next anchor in the first sync. Now
it sends 847 instead, which is wrong.
> Further subsequent syncs, even slow sync, doesn't ever sync this update
> to the laptop.
Just for the sake of completeness:
[2011-09-07 17:41:19.575] Saved Last Remote Client Anchor='847', received <last> Remote Client Anchor='847' (must match for normal sync)
[2011-09-07 17:41:19.575] Received <next> Remote Client Anchor='847' (to be compared with <last> in NEXT session)
[2011-09-07 17:41:19.575] (Saved) Last Local Server Anchor='20110907T213520Z', (generated) Next Local Server Anchor='20110907T214119Z' (sent to client as <last>/<next> in <alert>)
To me this looks like the phone doesn't properly distinguish among the
peers it syncs with. That pretty much breaks the sync topology where the
phone is the hub through which all data must pass.
Perhaps you can make your desktop that hub instead by synchronizing both
the laptop and the phone against it? USB Bluetooth dongles are cheap. Or
make the laptop the hub, synchronizing against the phone via Bluetooth
and against the desktop via HTTP
(http://syncevolution.org/wiki/http-server-howto).
--
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, 1 month
[SyncEvolution] UID matching during add<->add conflict
by Patrick Ohly
Hello!
Suppose the same meeting invitation for event UID=FOO is processed in
both Evolution and Google Calendar. On the Evolution side, the
invitation is accepted. In Google Calendar this is still open.
Both sides now have a new item when syncing takes place.
What happens is that the engine itself doesn't recognize that the two
new items are in fact the same. It asks both sides to store the others
item. The SyncEvolution EDS backend recognizes the UID and updates the
item, but without merging. The PARTSTAT=ACCEPTED is overwritten with
Google's PARTSTAT=NEEDS-ACTION. At the same time, Google's version of
the items similarly overwritten.
After modifying the event series in Evolution it is sent as update to
Google, at which point the correct PARTSTAT is lost everywhere.
Is there some way to force UID comparison for added items even in a
normal, incremental sync?
SyncEvolution already has a comparescript for its calendar types:
INTEGER RES;
if (COMPARISONMODE() != "age" && SESSIONVAR("VCALENDAR_COMPARE_UID") ) {
if (TARGET.UID == REFERENCE.UID &&
TARGET.ORIGSTART == REFERENCE.ORIGSTART) {
RES = 0;
} else {
RES = -999;
}
} else {
RES = COMPAREFIELDS();
}
return RES;
The VCALENDAR_COMPARE_UID session variable would be set in this case.
--
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, 2 months
[SyncEvolution] syncevolution config files
by Roger KeIrad
Hi,
how can i use or create the default syncevolution config files , i mean
files under /home/sst/.config/syncevolution/default/sources/ without the
creation of a peer (creation of template ) ?
THX .
10 years, 2 months
