On Mo, 2011-01-10 at 05:38 +0000, Dinesh wrote: > 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
What is the content of this IMAddress? There are fields for X-AIM and alike (AIM_HANDLE for the value, AIM_SLOT for the Evolution extensions which marks a location in the UI). This is currently done with a pair of fields for each chat protocol; a better solution would be to use arrays of value, type (AIM/ICQ/...) and slot. The problem was (and still is) that X-AIM and similar extensions cannot be mapped to such an array. Funambol and (as it seems) KDE have one extension in vCard, which would map to such a set of arrays. Perhaps we can write some script code for the built-in engine which copies between the fields depending on the direction of the data transfer. But that depends on knowing what kind of chat handle an IMAddress is. > here is the commit , please review it : > > > http://meego.gitorious.org/meego-middleware/saidinesh5-syncevolution/commit/650a12bc7ae09fc2609e28509c0ddc569305120c Makes sense. > If this is okay, I will add the remaining fields too ... (KABC stores > cryptographic keys etc.. as kde specific fields and the IM handles). Please do. > 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?? Right. There's one more thing: I suspect that in the code as given above, both X-EVOLUTION-MANAGER and X-KADDRESSBOOK-MANAGER will be encoded when storing in Akonadi. What is missing is one additional line and a slight change in the second: ===> <property name="X-EVOLUTION-MANAGER" suppressempty="yes" delayedparsing="1" profile="KDE"/> <property name="X-EVOLUTION-MANAGER" suppressempty="yes" delayedparsing="1" rule="other"> ^^^^^^^^^^^^ > 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. Knowing that would indeed be useful. -- 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
