[SyncEvolution] SyncEvolution 0.9 released: binaries available on http://syncevolution.org
by Patrick Ohly
SyncEvolution 0.9 has been released! SyncEvolution synchronizes personal
information management (PIM) data like contacts, calenders, tasks, and
memos using the SyncML information synchronization standard.
The 0.9 version replaces 0.8.1 as the stable version on Linux desktops.
Mac OS X and Maemo have not been updated and remain at 0.8.1 (hint:
volunteers wanted). 0.9 binaries in .deb, .tar.gz and (for the first
time) .rpm format are provided for x86 in 32 and 64 bit mode.
Moblin 2.0 comes with SyncEvolution included in the normal Moblin image,
with updates provided via the package repositories.
Planning and work for SyncEvolution 1.0 is in full swing. 1.0 is
intended to add the SyncML server role for direct synchronization with
other devices. If you want to get involved, then contact the team:
http://syncevolution.org/support
Changes SyncEvolution 0.8.1 -> 0.9
==================================
This is a major new release, with first steps towards further improvements.
>From this release on, the Synthesis SyncML engine will be the
underlying SyncML and data conversion engine.
A native GTK GUI is now included. The "sync-ui" program depends on a
backend D-Bus service ("synevo-dbus-server") and several auxiliary
files. Therefore, it only runs without hacks after installation in
/usr (possible with .deb, .rpm and binary .tar.gz archives, and
with "sudo make install", after compiling from source). The
normal command line tool still works without being installed.
In this release, the data handling model was changed from "all items
are sent verbatim to the SyncML server" to "parse and convert". The
argument for the former approach was that the SyncML server should be
the only entity in the system which does data conversion. The previous
releases already had to deviate from this approach to accommodate for
minor client/server incompatibilities and for vCard 2.1 support, so the
new approach just takes it one step further.
The main reason for going to full semantic conversion is vCalendar 1.0
support. Support by servers for iCalendar 2.0, the only format
supported by 0.8.1, is often still incomplete or even non-existent. By
doing the conversion on the client side, SyncEvolution is now able to
synchronize events and tasks with a wider variety of servers.
It is still true that properties not supported by a server cannot
be synchronized to other devices, so using a server with full
iCalendar 2.0 support is recommended. But in contrast to 0.8.1,
information that can be stored only locally is no longer lost when
receiving an incomplete update from the SyncML server, thanks to
intelligent merging, provided by the Synthesis engine. This depends on
an accurate description of the server's capabilities, which might not
be provided by all of them. This still needs to be tested in more detail.
Interoperability with servers tested extensively in this release.
The following servers are now supported:
* ScheduleWorld. There is very complete support for Evolution data. The
only known issues are around resuming from an interrupted sync.
* Google contact sync.
Google follows the vCard 2.1 specification, and thus does not support
some of the vCard 3.0 additions, nor some of the common extensions. As
a result, several properties are not synchronized (nickname, birthday,
spouse/manager, URLs, ...). Only one top-level organization seems to
be supported. For details, see README.google.
Regarding Google's SyncML support, refresh-from-client and
one-way-from-client sync modes are not supported. Deleting contacts
moves them out of the main address without deleting them permanently. When
adding such a contact again, the server discards the data sent by the
client and recreates the contact with the data that it remembered.
Because SSL certificate checking for Google works only with libsoup
if the platform has a patched libsoup
(http://bugzilla.gnome.org/show_bug.cgi?id=589323) or libsoup >=
2.28, certificate checking remains turned off by default for
Google. If your platform has a suitable libsoup (like Moblin 2.0),
then enable checking with:
syncevolution --configure \
--sync-property SSLVerifyServer=true \
--sync-property SSLVerifyHost=true \
google
* Funambol, with calendar and task support. Funambol supports iCalendar 2.0
in the current server, so this is enabled in the configuration template.
Not all iCalendar 2.0 features are supported by the server,
most notably support for meetings (drops attendees), meeting
invitations (drops UID), detached recurrences
(drops RECURRENCE-ID). See README.funambol for details.
Interoperability with the Funambol server was improved by adding
support for some vCard extensions (X-MANAGER/ASSISTANT/SPOUSE/ANNIVERSARY,
#2418). Lost ACTION property has a work around (#2422).
To enable that support in an existing configuration so that it
exchanges items in the more suitable iCalendar 2.0 format, use:
syncevolution --configure --source-type sync=two-way \
funambol calendar todo
syncevolution --configure --source-type type='calendar:text/calendar!' \
funambol calendar
syncevolution --configure --source-type type='todo:text/calendar!' \
funambol todo
Without the exclamation mark, format auto-negotiation would pick the
less capable vCalendar 1.0 format because that is marked as preferred
by the server.
*** WARNING ***: After switching from a previous release to the
current one, or vice versa, do a "syncevolution --sync
refresh-from-server" or "--sync refresh-from-client" (depending on
which side has the authoritative copy of the data) once, to get client
and server into a consistent state. Not doing so can result in
applying the same changes to the server multiple times, and thus
duplicates.
Other changes in detail:
* vCalendar 1.0 is now supported.
* Both libcurl and libsoup can be selected at compile time as HTTP(S)
transport mechanism.
* SF #2101015: Expect: 100-continue header results in 417 Error with proxy.
Should no longer occur with the HTTP transports in this release.
* SF #1874805: Syncing with Funambol results in loosing all-day property.
This now works thanks to the Synthesis data conversion rules.
* SF #2586600: Synchronisation with mobical.net fails in 0.8.1.
Works now, but there are some known issues (Bugzilla #3009)
and therefore mobical.net is not officially supported yet.
* SF #2542968: Separator for categories should not be escaped.
Done correctly by the Synthesis vcard conversion.
* bug fix: Evolution notes with only a summary and no description were
not sent correctly to the server. Instead of sending the summary,
an empty text was sent.
* CTRL-C no longer kills SyncEvolution right away. Instead it
asks the server to suspend the session. If that takes too
long, then pressing CTRL-C twice quickly will abort the sync
without waiting for the server (Warning, this may lead to a
slow sync in the next session).
* WBXML is enabled by default now, except for Funambol (#2415).
Using WBXML reduces message sizes and increases parsing
performance.
* New configuration templates can be added to
/etc/default/applications/syncevolution. These templates may contain
icons, which are used by the GUI (no icons shipped right now).
* Information about previous synchronization sessions is now stored in a
machine-readable format and can be accessed using the new
--print-sessions options. The output of this information is more
complete and more nicely formatted.
* --status now shows not only data changes since the last sync, but also
item changes (see README for the difference between the two).
* The new --restore option allows restoring local data to the state as
it was before or after a sync. For this to work, "logdir" must be set
(done by default for new configurations). The format of database dumps
was changed to implement this feature. Instead of in a flat file,
items are now saved as individual files in a directory. To get the
previous format back (for example, to import as one .vcf or .ics file
manually) concatenate these files.
* With --remove, one can remove configurations. It leaves data files and
the local databases untouched.
Known issues:
* The GUI includes the number of locally deleted items during a
refresh-from-server sync in the number of "received changes"
(#5185), which is a bit misleading. This is a result of #3314,
which introduced changes not "received" from the server.
* When a network error occurs and the client
never notices that the connection to the server was lost,
it will hang forever, waiting for the server's reply (#3427).
* The file backend now works only for data formats understood
by SyncEvolution and the Synthesis engine. Items are parsed
when exchanging them among the backend, engine, and server,
in contrast to 0.8.1, where item content was not touched
locally (#5046).
* The ZYB.com server sends conflicting sync anchors, so
most syncs don't work as expected (#2424).
* The sqlite demo and Mac OS X contacts backends do not compile
at the moment because they still need to be adapted to the
new infrastructure.
Source, Installation, Further information
=========================================
Main project page: http://syncevolution.org/
Technical information: http://moblin.org/projects/syncevolution/
Source snapshots are in
http://downloads.syncevolution.org/syncevolution/sources
Binaries for Debian-based distributions are available via the "stable"
syncevolution.org repository. Add the following entry to
your /apt/source.list, then install "syncevolution-evolution":
deb http://downloads.syncevolution.org/apt stable main
These binaries include the new "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 0.9 .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 0.9 possible:
http://syncevolution.org/about/contributors
11 years, 5 months
[SyncEvolution] [Bug 5388] New: [Stress] With 2500 PIM Data, "Change sync service" launching time may be 6 seconds
by bugzilla＠moblin.org
http://bugzilla.moblin.org/show_bug.cgi?id=5388
Summary: [Stress] With 2500 PIM Data, "Change sync service"
launching time may be 6 seconds
Classification: Moblin Projects
Product: SyncEvolution
Version: upstream
Platform: Netbook
OS/Version: Moblin Linux
Status: NEW
Severity: normal
Priority: Undecided
Component: GTK UI
AssignedTo: jku(a)linux.intel.com
ReportedBy: jingke.zhang(a)intel.com
QAContact: jingke.zhang(a)intel.com
CC: shuang.wan(a)intel.com, syncevolution(a)lists.intel.com
Release Milestone: Undecided
Image: distro 20090810-001
syncevolution: 0.8.1.99.6.09beta3.20090730
Description:
=====================
I have thought this is the same root cause to bug#5021 , but I used the 5021
fixing package to have a try. This issue still exists.
Once I got 2500 contacts in one service (e.g. Scheduleworld), I found it may
take 6 seconds to launch "Change sync service" window (for switching services).
If there is normally 200 data, the window can be launched very quickly and
smoothly.
Not 100% reproducable, but at least >50%.
Steps:
===================
1. Prepare 2500 PIM Data (either from importing or sync from service)
2. Launch syncUI.
3. Click "Cahnge sync service", it may take several seconds. Not 100% like this
but in high possibility. You can try some times.
--
Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.
11 years, 5 months
[SyncEvolution] Yongsheng's Weekly Report(ww32'09)
by Zhu, Yongsheng
Working on remaining issues of Mobical.net interoperability test(bug#3009). Almost done except comment#41 for this fix is needed to be further verified.
All fixes and workarounds are submitted to a branch and waiting to merge to master. Also there is a bug in libsynthesis and the fix is waiting to be merged.
TODO:
Refine improvement of nightly test and start to learn d-bus and existing d-bus api for GUI
Thanks,
Yongsheng
11 years, 5 months
[SyncEvolution] open tasks: 0.9.1, 1.0 and beyond
by Patrick Ohly
Hello!
Let me summarize what open tasks we currently have in SyncEvolution. I'm
intentionally including much more than what can possibly be covered by
the existing team, in the hope that new developers will step up and take
on some of these additional tasks. I'm using HTML formatting so that
links are easier to click. I'll go back to regular ASCII for other mail,
I promise.
This is just an overview. Detailed specification and discussion of
individual tasks should happen in bugzilla.moblin.org, so that we can
prioritize and track them. Whenever there is already an entry, I added
the issue number. If you are interested in working on something,
announce it here on the list. As soon as you are actively working on it,
also change the "assigned to" field in bugzilla.
"open" issues are considered essential for the release they are listed
under. "optional" means that we probably could release without them,
although that might not be desirable. "in progress" means that someone
is already working on it, with no help needed at the moment.
0.9
This is considered complete. Let's release it so that the Funambol-based
0.8.1 can be replaced.
Optional: support for Mac OS X and Maemo. Release 0.9 without binaries
for these platforms?!
For Mac OS X there isn't much choice: the code depends on the Funambol
"VOCL" vCard encoder/decoder, which is no longer available. Short of
adding it again (either the old GPL-licensed copy or the current AGPL
one) there's nothing that can be done in 0.9. It should be rewritten to
access the Synthesis field list.
0.9.1
First maintenance release.
In progress:
* resend messages - ready for testing post 0.9
* interoperability mobical.net, zyb.com
* internal SyncSource API rewrite (stretching the definition of
"maintenance" a bit, but this is very easy to test - if it
compiles, it should work)
Optional:
* rewrite Mac OS X backend to use field list (depends on API
rewrite)
1.0
First release with SyncML server and OBEX support.
In progress:
* incoming OBEX connections
* Synthesis SyncML server API
Open:
* outgoing OBEX connections
* database of URIs for each data category per vendor/device
* redesign and reimplement D-Bus API for GUIs
Optional (roughly sorted by importance and size):
* refactor libsynthesis into data conversion and SyncML parts
(libvxx?!)
* automatic syncs: at regular intervals, when local data changes,
when server data changes (push!)
* #5046 raw file sync source
* #5047 ODBC sync source
* #5049 field list sync source
* #5041 avoid use of stdout/cout, route through our own logging
code, #5043 move command line into D-Bus server
* #3479 EDS: protect against concurrent editing + revision
handling (depends on API changes in EDS)
* #4611 join/dejoin different sources
* #2069 Synthesis error codes and explanation, #4599 Funambol:
"Addressbook:Error 418" shows up in sync ui after syncing an
alike contact, #4576 Google: "Fatal dbs error" when syncing data
with google in "delete remote" mode
* #4815 Outlook meeting invitations: timezones
* #3472 code cleanup + quality improvements + #3476 Klocwork
* #2427: attachments in iCalendar 2.0 events/todo
* #4774 verify a server's conflict handling policy
* #2143 service setting changes should be tested with server right
away
* #2416 intelligent handling of unexpected slow syncs
* #2428 allow aliases for config options (user=username)
* #2429 HTTP AUTH
* #2432 rewrite synccompare in C++
* #3311 libsynthesis: field list <-> XML conversion
* #3313 push notification: via email and IMAP IDLE (or XMMP)
* #3477 local timezone
* #3604 command line: use keyring
* #2260 need interface to set useProxy or not
* #3471 libsynthesis: better configuration mechanism + debugging
* #3478 additional information about sync sessions
I have not included improvements to the current GTK GUI. There's plenty
of work left in that area. We rely solely on Jussi for that; I'm sure
help in that area would also be useful, although I'm less sure how to
arrange that.
These are all changes related to core infrastructure. Those who don't
want to get involved that deeply can pick up more specialized tasks:
* interoperability testing with additional servers, in particular
free (as in: no dependency on third-party operator) ones: Horde,
eGroupware
* adding additional backends: GPE and KDE have been asked for,
also Mac OS calendar sync
* wrap non-SyncML protocols or devices in a SyncML client:
extracting data via PBAP, BarrySync, IrMC, etc. and presenting
it as a local data backend in SyncEvolution would allow syncing
of that data with SyncEvolution and other SyncML servers.
Depending on those other protocols it might even be done as
two-way sync.
* more platforms: I already mentioned Mac OS X. Windows anyone?
--
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, 5 months
Re: [SyncEvolution] SyncEvolution
by Bob Eggers
Hi Patrick,
I have a few questions aimed at trying to understand what I see in the backend code samples. I've been looking at SyncEvolution 0.8, because I assumed it was more stable at this point in time. Anyway, my questions are a mix of my possibly false assumptions and actual questions:
1) In the backend, are all the uid parameters local UID's? Need we have any concern about mapping to remote ID? Is the engine handling that?
2) listAllItems(): the backend itemizes the entire local store and set revisions[<localUID>] with last revision stamp or modification time.
3) a) createItem(): generate a sync item data blob to ship to the server, which could be for add or update and we don't need to know?
b) insertItem(): either update or add item to the local store depending on whether UID already exists locally?
c) deleteitem(): delete item from the local store
Does the sync engine handle deleting items on server based on the results of listAllItems (UID's detected missing)?
4) Our contacts records do not have a last mod time
a) we are able to get a list of records that changed and another list of records deleted since last time we checked
b) if my assumption that items not appearing in the listAllItems will be deleted remotely by the engine, we can ignore this deleted list
c) with the changed records list, we could say last mod time is NOW (say, the start of sync), and set a custom field in the record to act as last mod time. (Will have to re-save the record locally.)
d) with unchanged records, do nothing but extract that last mod time from the custom field
5) exportData walks through all records and create item data blobs - presumably this is called in the slow sync scenario?
I appreciate your help - maybe these questions have been answered somewhere already. :)
Bob Eggers
________________________________________
From: Patrick Ohly [patrick.ohly(a)gmx.de]
Sent: Sunday, August 02, 2009 7:26 AM
To: Bob Eggers
Subject: Re: SyncEvolution
On Fri, 2009-07-31 at 08:51 -0700, Bob Eggers wrote:
> I am looking at using the Posix build of SyncEvolution to support a
> contacts client on the Palm webOS. I've been getting familiar with
> SyncML concepts and have looked at a few engines. I like SyncEvolution
> because of the WBXML support in particular.
You've mentioned Funambol and WBXML support in the same email - just to
be sure that there are no misunderstandings, you are aware of
SyncEvolution 0.9 using the Synthesis SyncML Engine? It no longer
depends on Funambol source code or libraries at all.
> One thing I'm struggling with is "getting it". I know I'm not the
> first because I saw a just such a comment today in a Funambol slide
> slow. The docs are generally sketchy, as you know, and the naming
> conventions they used were not always the clearest.
I might have inherited some of that in SyncEvolution :-/
> I have been studying backends that last couple of days trying to size
> up our task. I wonder if you might field a handful of questions from
> me? If so, let me know.
Sure, just go ahead. However, if you don't mind, can we have that
discussion on the SyncEvolution mailing list
(syncevolution(a)syncevolution.org)? Don't worry about subscribing (unless
you want to, of course), just mail me with that list on CC and I'll make
sure that all your emails get through.
That way answers will be available for others later on; the other
SyncEvolution developers might also be able to help.
--
Bye, Patrick Ohly
--
Patrick.Ohly(a)gmx.de
http://www.estamos.de/
11 years, 5 months
[SyncEvolution] Yongsheng's Weekly Report(ww31'09)
by Zhu, Yongsheng
Working on bug #4598 (Funambol company phone issue)and #3009(Mobical.net interoperability test)
1) Worked with Patrick and Mafulli from funambol. The root cause is found and patch was sent to funambol.
2) Start to make fixes and workarounds for issues in contacts, notes, tasks of Mobical.net due to its limitation and bugs. Calendars will be needed to investigate.
TODO:
Continue to follow #4598 and complete mobical interoperability test.
Thanks,
Yongsheng
11 years, 5 months
