On Thu, 2011-10-13 at 16:06 +0530, Chenthill wrote:
On Wed, 2011-10-12 at 10:39 +0000, Woodhouse, David wrote:
> On Wed, 2011-10-12 at 12:25 +0200, Patrick Ohly wrote:
> > David, how does the Evolution EWS backend handle this? Does it silently
> > throw away data or remap it when the EDS vCard doesn't fit into the EWS
> > data model?
>
> Hm, haven't looked very hard at the addressbook code; that's a question
> for Chen. Looking at the convert_contact_to_xml() function at
>
http://git.gnome.org/browse/evolution-ews/tree/src/addressbook/e-book-bac...
> I think we just iterate over the known properties and map them, and drop
> anything we don't have a mapping for.
>
> I'm not sure if we have a filter (or capability list) somewhere which
> prevents the UI from *adding* fields that we don't understand. That
> would make some sense, in the case where it is specifically an
> Exchange-based 'folder' in Evolution rather than being a file-based
> store which just happens to be synced today to Exchange.
At the moment, I have created a mapping for possible fields. The fields
which I was not able to match are,
<ContactSource/>,
<Generation/>,
<ImAddresses/>
<Mileage/>
<EffectiveRights/>
<ReceivedBy/>
<ReceivedRepresenting/>
[...]
The backends currently provide the fields that are
supported.
The problem is not just to find a mapping and document supported fields.
If EWS is following the Exchange data model, then it has additional
constraints even on the fields which have a mapping, doesn't it?
For ActiveSync, those constraints are:
* three different email addresses (without a way to mark them as
work/home/other)
* two postal addresses (one work, one home)
* ten different phone numbers:
* two business voice
* two home voice
* one business fax
* one business fax
* one cell
* one car
* one radio (whatever that means nowadays)
* one pager
Do these constraints also apply to EWS? What happens if a user creates a
contact with two cell phone numbers, for example?
--
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.