Hi Patrick, I have had a week of holidays last week, so fixed a few little things in syncevo , which includes adding all the custom fields, fixing an autotools problem, and started the work on the GUI myself. I have tested it against the Ovi servers, and here are the current problems:
Issues in vCard: 1)The 1st ; in ADR is causing it to leave out address as a blank.... (i think so) ADR;TYPE=dom;TYPE=home;TYPE=intl;TYPE=parcel;TYPE=postal;TYPE=pref;TYPE=work:123;;Planet Earth;Planet Earth;Planet Earth;Planet Earth;Home 2) "\" being expanded to "\\" and "," ot "\," in X-KADDRESSBOOK-CRYPTOPREF (not creating any problems though) X-KADDRESSBOOK-CRYPTOPROTOPREF:inline X-KADDRESSBOOK-CRYPTOPROTOPREF:inline openpgp\,openpgp/mime\,s/mime\,s/mim | openpgp\\\,openpgp/mime\\\,s/mime\\\ e opaque | ,s/mime opaque 3) As expected: the custom vcard fields give a problem , so how do i test these now? especially these ones which are being sent (more in commit log.) X-messaging/* The other KABC specific vcard fields are staying safe when synced. Also a strange behaviour is noted with some fields (ADDRESS being replaced by BDAY , URL being deleted locally, but appearing remotely, EMAIL Replaced by FN ). and apart from this, Syncevolution syncs as expected. (verified with Contacts and Calendar) I am looking into these issues, but if it is a known bug, please let me know. Apart from this, what is remaining is adding support for KJots as the Memo Application of the KDE PIM. in here, the issue is the data is of the format: MIME-Version: 1.0 Subject: Hello Content-Type: text/plain Ting tong So how do i approach this ? Overriding AkonadiMemoSource 's insertIem and readItem, to do the necessary conversions (something like a bijective function mapping the content of KJots item to VNOTE type ? ) vs. some other method like the vcard field lists conversion (if so, please elaborate) ? also is the vNote depricated or something and should vJournal be used in it's place? from this: http://blogs.gnome.org/rodrigo/2004/09/ "“The vNOTE object defined by the [IRMC] specifications was created because there was no journal entry capability in the original Versit/IMC vCalendar v1.0 specification. However, with adoption of the [ICAL] specification support for the vNOTE in the [IRMC] specification should be deprecated, in favor of support for the VJOURNAL calendar component in [ICAL]“. So," and as far as KDE PIM is concerned,"the journal stuff is deprecated, we should use the kjot format" So , going with KJots is safe right? Also , what else is needed so as to get my code merged with the main Syncevolution ?(Currently the plan is to release the command line tool first and later on the the GUI, Sivan ? Rohan ?, along with the Bluedevil plugin ). Cheers, Dinesh On Wed, Feb 2, 2011 at 1:19 PM, Dinesh <[email protected]> wrote: > Hi Patrick, > > I m still waiting to get a stable KDE PIM (4.6) to work on. I currently get > my KDE PIM from Project Neon(for Ubuntu) and Its been broken for the past 2 > weeks.(dont know if it was working before that) So couldn't really check > anything out. :( > > On a different note, I've contacted the KAddressbook maintainer about the > extensions problem and here is the summary of things: > > The "key" is s suppsed to be a unique identifier for an akonadi setup. The > user's akonadi stores the mapping between the "key"s and "title"s. So i > guess, we can't sync custom fields without an Akonadi <-> Akonadi sync. So > preserving the extensions locally seems to be the best available option. > Also, may be this will be a useful information for us When a vCard > containing the custom field, say "X-KADDRESSBOOK-abcd" s is imported into > another akonadi, in there, the title "abcd" is generated for the given > filed. > > The Neon Guys promised to get it running by this weekend though.. So may be > I can look into things after that. > > Cheers, > Dinesh > > > On Mon, Jan 31, 2011 at 7:29 PM, Patrick Ohly <[email protected]>wrote: > >> On Mo, 2011-01-10 at 16:12 +0000, Patrick Ohly wrote: >> > > X-KADDRESSBOOK-abc:asdf >> > > >> > > X-KADDRESSBOOK-abcd:2000-01-01T00:00:00 >> > > >> > > One can actually define the "key" after X-KADDRESSBOOK-*. >> > > My Guess is that the key is supposed to be unique (or else all but the >> > > data from the last key is wiped out, if the key is of the same >> > > "datatype", if the key is of different data type, the data is being >> > > reset), because the user can define a "Title" for each field he adds, >> > > and assign a "Value" to the title, and KAddressbook will take care of >> > > the mapping from keys to titles. I will confirm this with the >> > > maintainer soon. >> > >> > Knowing that would indeed be useful. >> >> Any update? Note that Lukas has implemented support for preserving >> arbitrary extensions (see his "luz" branch or the "master" branch on >> meego.gitorious.org), but it is not enabled yet in the SyncEvolution >> profiles. >> >> -- >> 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
