[SyncEvolution] merging phone branch
by Patrick Ohly
Hello!
I'm merging the "phone" branch, with changes for client-test testing of
syncing with the Nokia N7210c. Some comments...
ClientTest: Add a new test config for phones do not support UTC time.
Phones may not fully support UTC time. As the case for Nokia 7210c, it can
understand the UTC time sent by server but will not convert it back to UTC time
when sending back to server.
Use 'CLIENT_TEST_NOUTC' to use this special test configuration.
Your test data uses
TZID=/freeassociation.sourceforge.net/Tzfile/Asia/Shanghai. Will that
test work with phones using a different time zone?
+ env = getenv ("CLIENT_TEST_NOUTC");
+ if (env && !strcmp (env, "t")) {
+ if (!strcmp (type, "ical20")) {
+ type = (string (type) + "_noutc").c_str();
+ }
+ }
If I understand this right, CLIENT_TEST_SOURCES=ical20
CLIENT_TEST_NOUTC=t client-test Client::Sync::ical20 will work normally,
but use the test configuration for "ical20_noutc", right?
"type" is a const char * pointer. You point it towards a temporary
std::string buffer, which will leave you with a dangling pointer that is
not necessarily still pointing to allocated memory! I'll fix this after
merging.
Congwu, review the patch in the "pohly" branch and merge if you agree.
While you are at it, please also review the other pending patches in
that branch.
test/README.nokia_7210c: mentions the Google server. The rest of the
file was updated, I assume? ;-)
--
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, 10 months
[SyncEvolution] aborting before sending outgoing message?
by Patrick Ohly
Hello Congwu!
I have a question about abort handling and hope that you remember how
this was meant to work. Did we want to abort instead of sending a
message that was just generated by the Synthesis engine?
According to your code comment, this was the goal:
//check for abort, if so, modify step command for next step.
//We think abort is useful when the server is unresponsive or
//too slow to the user; therefore, we can delay abort at other
//points to this two points (before sending and before receiving
//the data).
if (checkForAbort() && (stepCmd == sysync::STEPCMD_RESENDDATA
|| stepCmd ==sysync::STEPCMD_SENDDATA
|| stepCmd == sysync::STEPCMD_NEEDDATA)) {
stepCmd = sysync::STEPCMD_ABORT;
}
I tried to abort before sending a message via some other means (script
sets a flag, flag gets checked in addition to checkForAbort()) and found
that this didn't work:
* SessionStep() returns STEPCMD_SENDDATA
* our case statement for that starts sending, then sets
STEPCMD_SENTDATA
* the code above is invoked, but doesn't abort
* SessionStep() is called with STEPCMD_SENTDATA, returns
STEPCMD_NEEDDATA
* our case statement for that waits, eventually might end up in
TransportAgent::FAILED (which checks for abort by itself) or
TransportAgent::GOT_REPLY (which doesn't check for abort and
instead goes to STEPCMD_GOTDATA)
In none of these cases does the checkForAbort() quoted above have any
effect, as far as I can tell. Do you know in which case it is needed?
Do we miss a check for abort directly after SessionStep and/or should
the code above perhaps be moved there?
--
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, 10 months
[SyncEvolution] status 2009-12-16
by Patrick Ohly
Hi!
Here's another summary of thing going on with SyncEvolution...
* HOWTOs for SyncEvolution 1.0 alpha as server available
* clarified goals and procedures for accepting outside
contributions
* merged first big contribution: an XMLRPC backend
* proposed talks at FOSDEM
In following up with the SyncEvolution 1.0 alpha release, HOWTOs about
setting up syncing with a phone and as HTTP server were published:
http://syncevolution.org/development/sync-phone
http://syncevolution.org/development/http-server-howto
For those compiling from source, note that the server-side admin data
format has changed last Thursday. Remove
sources/*/[.internal.ini|.server.ini] when updating to start from
scratch.
m-otion.com developed an XMLRPC backend which exchanges data via a web
API. After a brief Intel-internal discussion we came up with what I hope
is a very flexible and agreeable policy for accepting contributions
either with an informal copyright waiver, a more formal license
agreement or under an open source license. For details, see:
http://syncevolution.org/development
Proposed talks for FOSDEM, both a lightning talk and in the
cross-desktop devroom. Looking forward to meeting you there, whoever you
are! :-)
The mailing lists and syncevolution.org will be taken care of by our
Chinese colleagues while the rest of us take vacations over the
holidays.
Development:
* all: discussions around D-Bus restore API (MB #8144);
configuring client and server (MB #7838); handling unexpected
slow syncs (MB #2416) and recovery mode in the sync-UI
* Yongsheng: provide information about "waiting" state via D-Bus
API (MB #2229, needed for "spinner" in GUI); listing logs
possible without selecting a specific peer (MB #8049), analyzed
and reported a bug in the Memotoo server (incorrect size
calculation for items split across messages); ZYB.com for
contact sync is going to be supported in 1.0 (MB #2424)
* Congwu: fixed storing of server-side admin data;
more work on testing with Nokia 7210c, including workarounds for
sending time stamps as UTC
* Jussi: new settings GUI; draft for emergency view; fix for
sync-UI problem in alpha 1 when using localization (MB# 8618)
* Raji: workaround for exporting corrupt calendar events with
missing timezone definition (MB #7879)
* Patrick: more Oracle Beehive interoperability testing (and
ensuing discussions about interpretation of the iCalendar 2.0
standard...); fix building in non-GNOME environment (MB #8338);
workaround for libecal bug in error situation, avoids crash (MB
#8005); clarified file backend configuration (MB #8146); wrote
scripts to exchange patches with gdbus and libsynthesis for
shared files, sent patches to Marcel for merging into gdbus
Noteworthy new issues:
* user inquiries regarding supporting the native Maemo 5 calendar
(mailing list, MB #8511)
* More reports about OVI.com (doesn't send email addresses). We
are in the process of establishing contact with Nokia for
OVI.com.
* The Funambol server does not deal correctly with relative start
times of alarms. They get replaced with a fixed, one-time alarm
(MB #7806).
* sync-UI in alpha 1 has a problem setting up new configs when
localization is used. LC_ALL=en_US.UTF-8 should work around
that, fix is in master branch (MB #8618)
--
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, 10 months
[SyncEvolution] Nokia N900 - Syncevolution
by russ101
Having recently taken ownership of an n900, I must say it is impressive
however at this stage there is one thing that's really putting a spanner
in the works for me and that's being able to sync up with my syncml
address book and calendar.
My research prior to arrival of the phone lead me to believe that I
could use the same solution as my desktop and namely that syncevolution
would do the trick. Syncevolution is now installed on the phone and my
server configuration ported over from my pc but I've been unable to
establish what the configured data sources should map for the n900 or
whether it's just not supported???. Running syncevolution the n900
complains:
"calendar: type 'calendar' not supported by any of the backends
(syncebook.so.0 syncsqllite.so.0). The following backend(s) were not
found: syncecal.so.0, addressbok.so.0
Looking around, there is plenty of discussion about synevolution for the
n800 and older tablets but understandably at this stage there isn't a
great deal around specifically catering for the n900.
Just wondering if anyone has managed to get synevolution running on
their n900 against the default calendar and address book. I would love
to know for sure if this works and get something written up for other
people wanting to cross this bridge.
10 years, 10 months
[SyncEvolution] New backend for integration with web applications
by knipp＠m-otion.com
Dear all,
I've successfully finished an additional backend for syncevolution,
which connects to a web application using XMLRPC (using xmlrpc-c).
I'm planning to use this to connect our webmail application to an external
SyncML service, provided by O3SIS.
The file backend was used as template for the new backend, therefore
TrackingSyncSource is used.
Only four methods have to be implemented on the web application:
* listAllItems
* readItem
* insertItem
* removeItem
The URL for the web application as well as parameters like database,
username and password are configured using the evolutionsource
configuration parameter.
Even I'm no automake/autoconf expert, I've adapted the respective files,
so that my changes should integrate into the current building process
without troubles.
How would you like to integrate the new backend (which is a set of files
in their own backend directory) into the repository? May I push them back,
shall I send a patch?
Which is the preferred way to make the documentation for the configuration
as well the XMLRPC interface description?
How can I adopt the unit tests in a way, that a user configurable web
service can be set in the evolutionsource parameter?
Have a good day,
Franz
--
NEUE MOBILNUMMER: +43 660 4859550
Franz Knipp, Dipl.-Ing.
---------------------------------------------------------------------
knipp(a)m-otion.com
+43 660 4859550
https://www.xing.com/profile/Franz_Knipp
---------------------------------------------------------------------
m-otion GmbH
Favoritenstr 4-6/III, 1040 Wien
+43 1 205705 (Fax 99)
---------------------------------------------------------------------
www.m-otion.com
10 years, 10 months
[SyncEvolution] SyncEvolution 1.0 alpha 1: SyncML server, syncs with phone
by Patrick Ohly
Today we are releasing SyncEvolution 1.0 alpha 1, a development
snapshot, "because we can" :-)
In particular, we can:
* synchronize directly with a phone over Bluetooth/OBEX
* accept Bluetooth/OBEX connections in cooperation with obexd 0.19
* run SyncEvolution as a rudimentary HTTP SyncML server
* be reasonably sure that it compiles and runs as well as 0.9.x because
it passes the same nightly testing without known regressions
The main goal of this release is to get feedback on where we are going
with 1.0 and its SyncML server and direct synchronization features. If
you want to get involved, now is a good time because a) there is
something which works and b) there is still time to influence the
final 1.0, scheduled for March 2010.
This is definitely work in progress. Only a source snapshot is made
available, not the usual set of binaries. If you can, compile the latest
source directly from the git repositories and recheck before reporting
issues: http://syncevolution.org/development
The source tar ball itself is at the usual location:
http://downloads.syncevolution.org/syncevolution/sources/syncevolution-0....
Documentation is lacking at the moment. Watch the "Development"
section (http://syncevolution.org/development) for HOWTOs or ask on
the mailing list (http://syncevolution.org/support). Contributions
welcome, as always.
Here is a more complete list of features compared to the stable
release. The full (and up-to-date) list can be retrieved from the
Moblin Bugzilla (MB) issue tracking system with this query:
http://bugzilla.moblin.org/showdependencytree.cgi?id=7892&hide_resolved=0
Implemented features are marked with a plus +, open ones with a minus -.
Improved sync-UI:
+ settings for HTTP servers are now done inside the list of
all configs and server templates instead of poping up a
separate window
+ uses the new D-Bus API
+ no longer uses private gconf key to select default peer,
replaced by "defaultPeer" in SyncEvolution config
- the design is a bit tentative and not all of it is implemented;
for example, the triangle in front of server entries cannot
be used to unfold the entry, only the "setup now" button does
that (MB #8315)
- recovery features like restoring from backup and handling of
unexpected slow syncs (MB #2416) are missing
Redesigned and reimplemented D-Bus API:
+ central syncevo-dbus-server controls configurations and sync sessions:
http://syncevolution.org/development/direct-synchronization-aka-syncml-se...
+ accepts incoming SyncML connection requests and messages received by
independent transport stubs (obexd, HTTP server, ...)
+ can be used by multiple user interfaces at once
+ fully documented, see src/dbus/interfaces
+ no longer depends on dbus-glib with hand-written glue code for C++,
instead uses gdbus plus automatic C++ binding generated via C++ templates
- 'syncevolution' command line tool bypasses D-Bus server and runs
sync sessions itself (MB #5043)
- waiting for peer not reported over D-Bus and not shown in sync-ui (MB #2229)
- interactive password request not implemented yet (MB #6376)
- availability of peers not detected (connected for HTTP, paired for
Bluetooth; MB #7700)
- once started, syncevo-dbus-server keeps running forever (MB #7711)
- restoring backups only possible via command line (MB #8144)
Revised configuration layout (MB #8048, design document at
http://syncevolution.org/development/configuration-handling):
+ several peer-independent sync and source properties are shared
between multiple peers
+ they can be accessed without selecting a specific peer, by using an
empty config name or with the new "@<specific context>" syntax
+ user interface in command line and D-Bus API unchanged
+ old configurations can be read and written, without causing
unwanted slow syncs when moving between stable and unstable
SyncEvolution versions
+ old configurations can be migrated with the "--migrate" command
line switch; however, then older SyncEvolution can no longer
access them and migrating more than one old configuration causes
the second or later configuration to loose its "deviceId" property
(which is shared now), causing a slow sync once
- users of the sync-ui will not know about the --migrate option,
so if they have only one configuration, it should be migrated
automatically
SyncML server in general:
+ incoming connections are accepted by syncevo-dbus-server via
the D-Bus Connection API; because this is a "personal SyncML
server", all local data is meant to belong to a single user,
and only one sync session can be active at any point in time
+ different users on the same machine can run their own server,
as long as they ensure that listening for incoming connections
does not conflict with each other (different port in HTTP)
- suspend/resume support is untested (MB #2425)
- an HTTP client which stops sending messages blocks the
server forever (MB #7710)
- automatic backup of server databases is inefficient (done
even when client is not allowed to do a sync; always backs up
all data, including sources which are not active; MB #7708)
- the progress events and statistics reported for a SyncML client
are not generated when running as SyncML server, will require
a fair amount of refactoring in the Synthesis engine (MB #7709)
- the Synthesis serverexample config contains workarounds for
specific phones, but SyncEvolution does not currently use those;
adding new workarounds should be made very simple (MB #7712)
HTTP SyncML server:
+ test/syncevo-http-server.py provides an experimental HTTP server
based on Python and Twisted
- a configuration must be created for each peer manually, including
a remoteDeviceId value that contains the peer's SyncML device ID
(MB #7838)
OBEX SyncML server ("sync with phones"):
+ peers are contacted via a builtin transport that uses libopenobex (MB #5188)
+ Server Alerted Notification (SAN) message triggers syncs
- a configuration must be created for each peer manually, including
a syncURL that contains the peer's MAC address (MB #7838) and correct
settings for generating the SAN message (MB #7871)
- should be integrated into the system's Bluetooth pairing (MB #7089)
OBEX SyncML client:
+ obexd 0.19 contains a plugin which passes SyncML messages to syncevo-dbus-server
- parsing of SAN message is rudimentary and depends on an existing local
configuration, needs to be refined depending on which SyncML server software
it is meant to work with (MB #6175)
Automatic sync (MB #6378):
- no support for the various server push notification mechanisms
- no intelligent detection of local changes
- no regular background sync
- depends on safe handling of concurrent editing, which is blocked
by merging of a new Evolution Data Server API (MB #3479)
Upgrading from 0.9.x:
* Upgrading and downgrading should work seamlessly when using existing
configurations. But this being an alpha, better ensure that you have
backups of both your data and your configurations in
~/.config/syncevolution.
* The new configuration layout is only used when creating new
configurations or explicitly invoking "syncevolution --migrate" (see
above). Such configs cannot be used by older SyncEvolution releases.
SyncEvolution 0.9.2 is still in the pipeline. It is a minor update,
addressing several non-critical issues. All of these are also fixed in
1.0 alpha 1:
- Evolution Address Book: avoid picking CouchDB by default (MB #7877, evolution-couchdb #479110)
CouchDB address books are appended at the end of the local database
list, otherwise preserving the order of address books. The initial
release of evolution-couchdb in Ubuntu 9.10 is unusable because it
does not support the REV property.
Reordering the entries ensures that the CouchDB address book is not
used as the default database by SyncEvolution, as it happened in
Ubuntu 9.10. Users can still pick it intentionally via
"evolutionsource".
- installation: templates now in $(datadir)/syncevolution/templates (MB #7808)
This are files used internally, meant to be extended by distributors.
Storing them in /etc is no longer supported, but also unlikely to be
needed. Added warnings that these files cannot simply be copied into
.config because they are not complete configurations.
- installation: "make install" populates $(docdir) (MB #7168)
Previously README, COPYING, NEWS, and server READMEs were copied
into syncevolution.org .tar.gz/.deb/.rpm archives as part of
custom make rules and thus missing in other installations.
- autotools + Boost: --with-boost had no effect (MB#7856)
- configure: detect incorrect use of --with-synthesis-src
- stderr redirection: detect "error" messages and show them (MB#7655)
The "GConf Error: Failed to contact configuration server..." error
message was suppressed by the code which catches noise from libraries
invoked by SyncEvolution. Now it is printed as ERROR, making it
easier to detect why running SyncEvolution inside cron needs
additional changes:
http://www.estamos.de/blog/2009/05/08/running-syncevolution-as-cron-job/
--
Patrick Ohly, on behalf of everyone who has helped
to make SyncEvolution 0.9.x possible:
http://syncevolution.org/about/contributors
10 years, 10 months
[SyncEvolution] status (error) value constraints
by Jussi Kukkonen
I was working on improving error reporting and couldn't easily tell if I
could trust some assumptions about the status codes... Patrick suggested
I write my assumptions here, and we decide if they should be added to
the spec or that they should not be relied on.
I've phrased these as questions so no-one takes these as explanations of
status quo: I really couldn't tell what to expect.
* if there is a non-zero source status, will sync status be non-zero?
* Can there be different sources with different non-zero source status
codes in a single sync?
* StatusChanged signal can obviously include zero status and later
non-zero status. Can one source have several non-zero statuses (as in
0 -> LOCERR_USERSUSPEND -> LOCERR_TIMEOUT)?
* Are the last StatusChanged status codes the same as the ones in the
sync report that will be available?
* Are there other "non-error" status codes in addition to these:
LOCERR_USERABORT, LOCERR_USERSUSPEND?
- Jussi
---------------------------------------------------------------------
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki
Business Identity Code: 0357606 - 4
Domiciled in Helsinki
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
10 years, 10 months
[SyncEvolution] Compilation on RHEL/CentOS 5.3
by knipp＠m-otion.com
I just want to share my experience of the installation of SyncEvolution on
RHEL 5.3:
== Prerequisites ==
Some packages are necessary for compilation from source.
yum search libtool glib2-devel intltool boost-devel sqlite-devel
The boost libraries provided by RedHat are too old, therefore a new
package is compiled from source.
yum install bzip2-devel python-devel libicu-devel
wget http://download.fedora.redhat.com/pub/fedora/linux/updates/testing/10/SRP...
rpmbuild --rebuild boost-1.34.1-18.fc10.src.rpm
rpm -i /usr/src/redhat/RPMS/x86_64/boost-1.34.1-18.x86_64.rpm /usr/src/redhat/RPMS/x86_64/boost-devel-1.34.1-18.x86_64.rpm
== Preparation of Makefile.am ==
Because of an old version of automake, the docdir has to be set in
Makefile-gen.am and src/Makefile-gen.am
diff --git a/Makefile-gen.am b/Makefile-gen.am
index f304225..5584175 100644
--- a/Makefile-gen.am
+++ b/Makefile-gen.am
@@ -1,3 +1,4 @@
+docdir = ${datadir}/doc/${PACKAGE}
## Process this file with automake to produce Makefile.in
ACLOCAL_AMFLAGS = -I m4 -I m4-repo
diff --git a/src/Makefile-gen.am b/src/Makefile-gen.am
index 15d9e33..b6eea3f 100644
--- a/src/Makefile-gen.am
+++ b/src/Makefile-gen.am
@@ -1,3 +1,4 @@
+docdir = ${datadir}/doc/${PACKAGE}
BACKENDS = @BACKENDS@
service_in_files = org.syncevolution.service.in
== Compilation ==
Finally, SyncEvolution can be built and installed.
./autogen.sh
mkdir -p src/synthesis-workdir/m4
./configure -with-synthesis-src=http://git.moblin.org/libsynthesis.git --disable-ebook --disable-ecal
make
make install
--
NEUE MOBILNUMMER: +43 660 4859550
Franz Knipp, Dipl.-Ing.
---------------------------------------------------------------------
knipp(a)m-otion.com
+43 660 4859550
https://www.xing.com/profile/Franz_Knipp
---------------------------------------------------------------------
m-otion GmbH
Favoritenstr 4-6/III, 1040 Wien
+43 1 205705 (Fax 99)
---------------------------------------------------------------------
www.m-otion.com
10 years, 10 months
[SyncEvolution] Strange empty events in myFUNAMBOL
by Stefano Maffulli
hi
we noticed that many syncevolution users in myFUNAMBOL database have
events with summary 'unnamed', body 'unnamed', no dtstart and no dtend.
The problem with this kind of events is that they duplicate wildly in
the database.
Since my calendar on myFUNAMBOL also contains two unnamed events, but I
cannot find such events on Evolution. I have tried searching events that
contain 'unnamed' in their body or summary but nothing shows up in
Evolution UI, while they are visbile in the backup directory of
SyncEvolution. This is an example:
BEGIN:VCALENDAR
PRODID:-//Ximian//NONSGML Evolution Calendar//EN
VERSION:2.0
METHOD:PUBLISH
BEGIN:VEVENT
CLASS:PUBLIC
PRIORITY:0
SUMMARY:unnamed
DESCRIPTION:unnamed
UID:20091014T160856Z-8778-1000-1-43@biancone
DTSTAMP:20091014T160856Z
CREATED:20091014T160856Z
LAST-MODIFIED:20091014T160856Z
END:VEVENT
END:VCALENDAR
The weird thing is that in myFUNAMBOL table there are two events, but in
SyncEvolution backup dirs I find only one. After a slow sync there are 5
unnamed events in the database and 3 in the dir
backup/SyncEvolution-funambol-2009-12-04-09-57/calendar.after
We're investigating further, but we still haven't found a way to
reproduce. Did anybody notice anything like this before?
BTW, is there any way to count the total number of events stored in
Evolution?
cheers,
stef
--
Funambol :: Open Source Mobile Cloud Sync and Push Email
Community manager :: https://www.forge.funambol.org
Follow the tweets: http://twitter.com/funambol
Funambol Identi.ca group: http://identi.ca/group/funambol
10 years, 10 months
[SyncEvolution] Faster synchronisations on TrackingSyncSource-based backends?
by knipp＠m-otion.com
During writing the XMLRPC backend I recognised a high number of
readItem operations, at least when using the command line interface:
1. A list of the items is generated (listAllItems)
2. All items are read (n times readItem)
3. listAllItems is called for synchronisation (listAllItems)
4. Data is changed (readItem, insertItem, removeItem)
5. The new of items is read (listAllItems)
6. All items are read (n times readItem)
1+2 as well as 5+6 seem to be the dumping of the database for logging (and
maybe recovery) purposes.
During a normal synchronisation run they are not necessary as far as I
see.
As I didn't find a way to switch off these steps by configuration, I made
the following patch:
diff --git a/src/syncevolution.cpp b/src/syncevolution.cpp
index d7bc87a..c4e4fe7 100644
--- a/src/syncevolution.cpp
+++ b/src/syncevolution.cpp
@@ -79,7 +79,7 @@ class KeyringSyncCmdline : public Cmdline {
* create a user implemented sync client.
*/
SyncContext* createSyncClient() {
- return new CmdlineSyncClient(m_server, true, m_keyring);
+ return new CmdlineSyncClient(m_server, false, m_keyring);
}
};
Is there anything that would break by using this modification? My tests
went well up to now. Is there the need to active such a behaviour by a
command line switch? In this case, I could prepare a patch.
--
NEUE MOBILNUMMER: +43 660 4859550
Franz Knipp, Dipl.-Ing.
---------------------------------------------------------------------
knipp(a)m-otion.com
+43 660 4859550
https://www.xing.com/profile/Franz_Knipp
---------------------------------------------------------------------
m-otion GmbH
Favoritenstr 4-6/III, 1040 Wien
+43 1 205705 (Fax 99)
---------------------------------------------------------------------
www.m-otion.com
10 years, 10 months