12:50 p.m.
Hello!
I'm currently looking at the eas<->vCard 3.0 conversion in activesyncd.
It is partly broken (one cannot do strcpy of the BDAY value between the
two, the format is different; EMAIL without attribute was ignored).
That's easy enough to fix, but there's a more fundamental issue.
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?
For email, the current approach is to fill the three slots with the
first three EMAIL properties. There's not much that can be done
differently.
For postal addresses it becomes more interesting: if a vCard has two
WORK ADR, should one be stored as business and the other as home
address? At least it would be stored, albeit with the wrong type.
Same for things like cell phone. I'm certain that some of my address
book entries have more than one TEL with TYPE=CELL.
Right now I am leaning towards keeping activesyncd simple. Let it store
vCards that match the EAS data model, but don't worry about those who
don't.
That pushes the problem towards SyncEvolution. It doesn't make it easier
to solve, but that's where the solution conceptually belongs.
On the other hand, SyncEvolution doesn't really know about these
limitations of a specific ActiveSync server. I bet it does depend on the
specific ActiveSync protocol revision, which is not exposed to
SyncEvolution at the moment - at least not via the libeassync API.
I could rant now about the pros and cons of a fixed data model that is
specified as part of a synchronization protocol. There are advantages,
but only as long as you don't need anything that isn't included. With
Evolution<->Google synchronization via ActiveSync we'll have the
"ironic" situation that both sides support arbitrary number of phone
numbers, but they can't synchronize that against each other.
With ActiveSync, that is a limitation of the protocol. With SyncML, the
limitation is often in the implementation - not better in practice, but
at least it could be fixed :-/ For example, Google's SyncML
implementation doesn't support BDAY, although it could.
--
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.