On Mon, 2011-09-05 at 13:50 +0200, Patrick Ohly wrote:
> ActiveSync has a fixed data model, which in the case of contacts only
> supports:
> * 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
>
> This is a subset of what vCard supports. Conversion to vCard is possible
> without data loss.
>
> The challenge now is: should the vCard to EAS conversion try to be smart
> and preserve as much data as possible, or should it set what it can and
> ignore the rest?
Here's an analysis of what Google does. I created a contact with
multiple cell phone numbers, two home addresses, multiple email
addresses, birthday, anniversary and one custom field in Google's web
interface.
The exported vCard is attached. It seems to be formatted for Apple's
addressbook app (grouping, X-ABDATE/X-ABLabel).
When downloading via ActiveSync, Google provides the following
information:
- first home address
- first work address
- birthday
- first three email addresses
- first cell phone number
Repeating the test with an unmarked address (neither home nor work)
defined after home and work address shows that it is picked first.
Now the interesting question becomes: what happens when modifying the
contact locally and sending back?
Inserting "-mod" into one email sends the following change request to
the server:
<Change>
<ServerId>8311029996633923674</ServerId>
<ApplicationData>
<LastName>Contact</LastName>
<FirstName>Test</FirstName>
<FileAs>Contact, Test</FileAs>
<MobilePhoneNumber>mobile phone 1</MobilePhoneNumber>
<Email1Address>hom...@email.com</Email1Address>
<Email2Address>hom...@remail.com</Email2Address>
==> <Email3Address>home-1-...@email.com</Email3Address>
==> <HomeStreet>PO BOX</HomeStreet>
<HomeCity>city</HomeCity>
<HomeState>state</HomeState>
<HomePostalCode>zip code</HomePostalCode>
<HomeCountry>region</HomeCountry>
<BusinessStreet>work address 1</BusinessStreet>
<Birthday>2000-01-01T00:00:00.000Z</Birthday>
</ApplicationData>
</Change>
The first change is intentional, the second one is an undesired side
effect of editing in Evolution. Somehow PO box and street got mixed up
somewhere. Google combined its "PO BOX", "Street" and "Neighborhood"
into one field when sending the contact and Evolution took it apart.
Needs further investigation.
After sending, the contact is modified in the web interface as expected.
The type of the email addresses was changed from "Home" to "Other", but
at least the rest of the data was preserved.
Now let's see whether we can remove some of the fields on the client. I
removed the three email addresses. Nope, that didn't work. Google keeps
the removed email addresses after being sent:
<ApplicationData>
<LastName>Contact</LastName>
<FirstName>Test</FirstName>
<FileAs>Contact, Test</FileAs>
<MobilePhoneNumber>mobile phone 1</MobilePhoneNumber>
<HomeStreet>PO BOX</HomeStreet>
<HomeCity>city</HomeCity>
<HomeState>state</HomeState>
<HomePostalCode>zip code</HomePostalCode>
<HomeCountry>region</HomeCountry>
<BusinessStreet>work address 1</BusinessStreet>
<Birthday>2000-01-01T00:00:00.000Z</Birthday>
</ApplicationData>
Now this could be a case of "to remove a value, explicitly send an empty
one". The encoder in the activesyncd doesn't do that at the moment. Need
to check.
So the model that the server seems to follow is this:
- expose a subset of the contact properties via ActiveSync
- only make changes inside that subset
SyncEvolution would have to do the same on the client side, to avoid
loosing data when the local contact is more complex than what ActiveSync
supports. Not a trivial task because the ActiveSync limitations defy
simple descriptions like "supports email addresses".
I think the effort would be better spent on writing a GData backend for
SyncEvolution. That would allow to synchronize *all* data, something
which cannot be achieved with ActiveSync.
--
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.
BEGIN:VCARD
VERSION:3.0
FN:Test Contact
N:Contact;Test;;;
EMAIL;TYPE=INTERNET;TYPE=HOME:hom...@email.com
EMAIL;TYPE=INTERNET;TYPE=HOME:hom...@remail.com
EMAIL;TYPE=INTERNET;TYPE=HOME:hom...@email.com
EMAIL;TYPE=INTERNET;TYPE=HOME:hom...@email.com
EMAIL;TYPE=INTERNET;TYPE=WORK:wor...@email.com
EMAIL;TYPE=INTERNET;TYPE=WORK:wor...@email.com
TEL;TYPE=CELL:mobile phone 1
TEL;TYPE=CELL:mobile phone 2
TEL;TYPE=CELL:mobile phone 3
ADR;TYPE=HOME:;home address 1\nPO BOX\nneighborhood\, city\, state zip code
\nregion;;;;;
ADR;TYPE=WORK:;work address 1;;;;;
ADR;TYPE=HOME:;home address 2;;;;;
BDAY:2000-01-01
item1.X-ABDATE:2010-01-02
item1.X-ABLabel:_$!<Anniversary>!$_
NOTE:Anniversary: 01/02 2010\nmy extension: custom
END:VCARD
_______________________________________________
SyncEvolution mailing list
SyncEvolution@syncevolution.org
http://lists.syncevolution.org/listinfo/syncevolution
