Hi all,
I now have one version that I would consider working and of preproduction
state.

Next steps
Is someone willing to test it, or how would you proceed in this case?
I do not have cal/carddav accounts or any of the other supported peers.
I have only two phones I could test with - Nokia 5530 and Nokia N9.
It would be interesting to test with other phones, devices, systems etc. -
at least the contacts and the calendar ( which I believe work fine now).

Contacts and Calendar
I tested address book (contacts) and calendar (events) extensively on both
phones.

Todos and Memos (journal)
The 5530 has some strange calendar type, so todo and memo worked only from
phone to TDE, but not v.v. for obvious reason. I am waiting now for some
hints on how to configure (perhaps virtual calendar or special settings).
On the N9 I did not test those extensively. I tested briefly todos and it
works fine. Memos in N9 are TDE/Knotes (see below).

Notes
I also did not implement the classical KDE/TDE notes - but I will soon do so
as this will be helpful for the N9 (and perhaps other phones/systems/peers
too). I have the basic structure and functions, but this goes into a
separate plugin and was not a prio.

Build 
As SyncEvolution is using the automake system, the code is integrated into
it. (Not sure if this is of any interest)

Packaging
SyncEvolution is provided by debian main line.
Should the code be pushed there or we could provide a deb package with the
tdepim part from within trinity?
I am not sure if the debian main line will work with it. I had to explicitly
disable some configure options to have it working. What does one do in such
a case? Provide the full package? I would need some help here and
brainstorming as well.

Code availability
Where would you upload the code for testing in this case? What is
the "standard" procedure. I dislike google but have account @sourceforge
Is the latter good to go?

Optimization 
There were some good advises from Fat-Zer regarding string encoding, but I
couldn't follow (as my time window is closing now), so I still convert the
TQString into std::string and then assign the content. (One could save some
memory here and there).

valgrind does not complain about the code - it looks clean.

Fun
I had some issue yesterday on the test env (2G mem) where it crashed,
because of memory exhausted. It turned out that opening the log file in
konqueror consumed 1,7G :D ... I was thinking for a moment - come one, you
were just syncing fine until last start of the virutal machine ... WTF
happened, but it was the konqueror and the log file :D

I also didn't follow up with the parseVCard - I'm not sure if it needs to be
handled as a bug - it seems to be left over from the babylonian times, but
someone has to retest and work it out properly and I do not think that I
could spend the time now and take the responsibility.

thanks in advance for your patience and support
regards