On Mo, 2011-04-25 at 02:36 +0100, Dinesh wrote: > Hi Patrick > > On Thu, Apr 21, 2011 at 4:46 PM, Patrick Ohly <[email protected]> > wrote: > Hello! > > Since merging the Akonadi code, I focused on stabilizing and > testing in > preparation for 1.1.99.4. I wanted to get a new update out > this week; > unfortunately I am not yet ready to include Akonadi in the > binaries or > the nightly testing. > > Here are the details: > * I re-did the vCard extensions to avoid affecting > non-Akonadi > syncs. Dinesh, please review the commit and re-test > with > Akonadi. So far I only verified that the existing > nightly > testing continues as it did before the merge. > * I fixed various other, minor build issues. > * I updated the reference build platform from Ubuntu > Hardy 8.04 to > Ubuntu Lucid 10.04. Both are long-term support > releases. The > advantage is that 10.04 contains a recent enough > Akonadi; on > 8.04 the code didn't compile cleanly. So theoretically, > syncevolution.org binaries can now be built including > EDS and > Akonadi support. > > > Great :) > Although the important thing for us is that we can only support KDE > PIM 4.6(All Akonadi...) onwards and it is not yet out, so both 10.04 > and 8.04 shouldn't make much of a difference for us. I hope we will > have the KDE PIM 4.6 by Kubuntu 11.10.
So in platforms like Ubuntu Lucid and Debian Squeeze (current stable), what is Akonadi really used for? It's certainly in the platform. Are you saying that KDE doesn't fully use it yet? Then how useful is synchronizing data stored in it before KDE PIM 4.6? I am not keen on having to provide pre-compiled binaries for lots of platforms. If I can make it work by compiling on Ubuntu Lucid, my life would be a lot easier. > Open issues: > * When KDE is active, crashes are caught by KApplication, > which > leads to a GUI dialog about reporting the crash. This > might be > useful, but where does it report the problem to? Can > this be > disabled if it turns out to be not so useful? > > Currently it will finally lead to KMail, where the user can manually > mail the Backtrace and other information (s)he wishes to provide to > [email protected]. That should be fine. > * If both Akonadi and EDS are enabled and installed, which > backend > does "backend = addressbook/calendar/todo/memo" choose? Both > EDS > and Akonadi backends recognize such generic names. The original > goal was to let the person compiling SyncEvolution decide (by > only enabling the desired backend) or the user (by installing > only the right backend). The latter depends on packaging > backends separately, which is not currently done for > syncevolution.org binaries. There is only > "syncevolution-evolution". > > Note that I had always intentionally added the -evolution suffix to > denote the package for EDS. I could try to create "syncevolution" > core, > "syncevolution-evolution" and "syncevolution-kde". Not sure how easy > that is. Either way, I would prefer and additional solution: > * Introduce a SyncConfig::isPlatform(type) with type == > GNOME/KDE/... plus possibly other values. > * EDS backends only react to generic names if platform == GNOME. > * Akonadi only if platform == KDE. > * The check itself can be based on the KDE env variable, at the > moment. If not set, assume GNOME. > * The KWallet check also needs to use isPlatform(). > > Later on we can make isPlatform() more sophisticated and even > configurable via a global config option. > > Dinesh, can you prepare and test a patch for these issues? > > Sounds good to me :) but currently I am in the midst of my University > exams.(they start tomorrow).... would be relieved after the first > week of May.. So will get to work immediately after that... so can > this wait till 15th of the next month? (along with 2 code clean up > patches in the queue for the KJots specific sync) As of now, the code > successfully builds and everything works as it was before :) 15th next month may be too late for a SyncEvolution 1.2 release. But we could do a 1.2.1 update shortly afterwards which then would include Akonadi support. > About testing Akonadi sources, should this be based on Ovi or some of > the more mainstream servers, like Memotoo? In my testing with Ovi, I > had > quite a lot of problems with network errors and timeouts. > > > At this point of time I currently only use Ovi, because of the Ovi > sprint in which we sent them a document for additional support. And I > really haven't heard from them after that. And I dunno what to expect, > especially after the Nokia Microsoft thing. So I think it is good that > we test them against other mainstream servers too. Okay, so let's do that first. > Also you might be interested in the results of our first Akonadi <--> > Akonadi Syncresults via. syncevolution http server.. I m attaching the > file.. Almost everything is as expected, except for > > ADR;TYPE=DOM;TYPE=HOME;TYPE=INTL;TYPE | > ADR;TYPE=HOME;TYPE=WORK:123;;Planet E, ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Not supported like this in the internal Synthesis representation. From the vCard profile: <parameter name="TYPE" default="yes" positional="no" show="yes"> <value field="ADR_STREET_FLAGS" conversion="multimix" combine=","> <enum name="HOME" value="B0"/> <enum name="WORK" value="B1"/> <enum mode="ignore" value="B2"/> <!-- OTHER --> <!-- enum mode="prefix" name="X-CustomLabel-" value="1.L"/ --> <!-- enum mode="prefix" name="X-Synthesis-Ref" value="2.L"/ --> </value> </parameter> We would have to add other types. BTW, does combining TYPE=DOM and TYPE=INTL really make sense? From the RFC: The TYPE parameter values can include "dom" to indicate a domestic delivery address; "intl" to indicate an international delivery address That sounds mutually exclusive to me. > The Birthday changing the format >From 2010-12-31 to 20101231 or vice versa? Both is allowed. As long as KDE swallows the format produced by the Synthesis encoder, we don't need to worry. > The Photo showing differences, even though the other end didn't > change the photo.. Reencoding somewhere? A log at loglevel=4 would show us more - typically that is needed when tracking down data conversion issues. > The , being expanded to \, and \ being expanded to \\ with Ovi > servers isn't happening here... > ------------------------- and > X-KADDRESSBOOK-OPENPGPFP:E51B7150FAF9 | ys > > > DFD3598EA760C7A89F438818028A Same here: hard to tell without full log. -- 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. _______________________________________________ SyncEvolution mailing list [email protected] http://lists.syncevolution.org/listinfo/syncevolution
