4:12 p.m.
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/comm...
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.