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.


On Mon, Jan 31, 2011 at 7:29 PM, Patrick Ohly <patrick.ohly@intel.com> 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

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.