Hello Patrick,

Sorry for the delayed reply : was terribly busy the last few days...
Here is the summary
The default fields are:

X-KADDRESSBOOK-BlogFeed  :  BLOGURL
X-KADDRESSBOOK-X-Anniversary : ANNIVERSARY
X-KADDRESSBOOK-X-AssistantsName : ASSISTANT
X-KADDRESSBOOK-X-ManagersName : MANAGER
X-KADDRESSBOOK-X-Office : ORG_OFFICE
X-KADDRESSBOOK-X-SpouseName : SPOUSE

and i am a bit doubtful of 
X-KADDRESSBOOK-X-Profession : which i am mapping to ROLE.

I couldnt find any alternative for X-KADDRESSBOOK-X-IMAddress, So i added a field in 00vcard-filelist.xml
X-KADDRESSBOOK-X-IMAddress

here is the commit , please review it :

http://meego.gitorious.org/meego-middleware/saidinesh5-syncevolution/commit/650a12bc7ae09fc2609e28509c0ddc569305120c

If this is okay, I will add the remaining fields too ... (KABC stores cryptographic keys etc.. as kde specific fields and the IM handles).

 
Yes to both. Use rule="KDE". Here's what it should look like:


       <!-- item for SyncML server: EVOLUTION rule not active,
            both X-EVOLUTION-MANAGER and X-MANAGER are sent.

            item from SyncML server: EVOLUTION rule not active,
            both X-EVOLUTION-MANAGER and X-MANAGER are checked,
            but X-EVOLUTION-MANAGER later so that it overwrites
            a value set earlier by X-MANAGER (if any). This is
            a more or less arbitrary priority, chosen because
            servers that know about SyncEvolution (ScheduleWorld,
            Memotoo) use the X-EVOLUTION variant.

            item to/from Evolution: EVOLUTION rule is active,
            only X-EVOLUTION-MANAGER is used. -->
       <property name="X-EVOLUTION-MANAGER" suppressempty="yes" delayedparsing="1">
         <value field="MANAGER" show="yes"/>
       </property>
       <property name="X-MANAGER" suppressempty="yes" rule="EVOLUTION"/> <!-- disables the X-MANAGER for EVOLUTION -->
       <property name="X-MANAGER" suppressempty="yes" rule="KDE"/> <!-- disables the X-MANAGER for KDE -->
       <property name="X-MANAGER" suppressempty="yes" rule="other">
         <value field="MANAGER" show="yes"/>
       </property>
 
       <!-- only enable this when talking to KDE backend -->
       <property name"X-KADDRESSBOOK-SPOUSE" rule="KDE">
         <value field="MANAGER"/>
       </property>
 
you mean <value field="SPOUSE">  right??


Note that there was some dispute about the name of the X- extensions
used by KDE. I picked something as placeholder above from memory, better
check this with real test data.

> Also certain fields ,like SPOUSE, are in both Evolution and
> KAddressbook. So should I be using the same field name for both? 

Yes, absolutely. The field name must be the same, so that the Synthesis
engine can do the mapping in the different profiles.

I have not forgotten that you also want to handle arbitrary extensions
as defined by users of the KDE suite. Can you give an example how such
extensions look like? Is allowed to have the same X-FOOBAR property
multiple times?

Basically The extensions are of the form: 

X-KADDRESSBOOK-45362fae-abd7-4ab7-bc3f-7b222cec2c67:me

X-KADDRESSBOOK-CRYPTOENCRYPTPREF:alwaysIfPossible
X-KADDRESSBOOK-CRYPTOPROTOPREF:inline openpgp\,openpgp/mime\,s/mime\,s/mime
  opaque

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.

Once this is reviewed, i will have to add the remainder of the fields and also solve, the weird KOrganizer bug.

Cheers,
Dinesh


--
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
SyncEvolution@syncevolution.org
http://lists.syncevolution.org/listinfo/syncevolution