Hello!
This is related to http://bugzilla.moblin.org/show_bug.cgi?id=10462
Steps to reproduce:
- sync Synthesis iPhone client, SyncEvolution server, Evolution
- modify contact on iPhone
- send to server and Evolution
- TYPE="X-Synthesis-Ref0" is added to ADR, EMAIL, TEL
Outcome:
- Evolution shows email as "other" (might be right, there was no
TYPE=HOME/WORK)
- ADR is not shown (NOT right!)
Our XML configuration contains the TYPE=X-Synthesis-x extensions. We
inherited
those from the Synthesis example config. Having them is useful when
operating
as server with the file backend, because the iPhone client can store
and later
retrieve its extensions.
But when storing an item in Evolution, we should not add these
extensions.
Implementing that is tricky, because we don't want to maintain two
different
sets of vcard profiles. Not sure how to do this yet.
I have a few questions about this. First, X-Synthesis-Refx maps to the
field ADR_STREET_ID with value x. What is the semantic of this? Same for
ADR_STREET_LABEL, which would show up as X-CustomLabel-<label>. I'm
asking to figure out whether this might be worth mapping to something in
Evolution or elsewhere.
Second, how does the Synthesis server handle synchronization between
clients which support this extensions and those that don't? The DevInf
does not contain entries for these extensions, so the server cannot tell
whether a client supports them or not.
Third, are there perhaps other clients which get confused by these
extensions? At least ScheduleWorld might preserve them (not entirely
sure).
Regarding solving this problem, the obvious choice would be to make
X-Synthesis-Ref depend on a specific rule: when encoding for Evolution,
don't enable the extension. But this is not possible at the moment.
I suppose for SyncEvolution 1.0 we should simply remove the extension
from the XML config used by us. There's a slight loss of functionality
when SyncEvolution is used as server for a Synthesis (iPhone) client,
but that is not its primary role anyway.
Then later on we should either enhance the "rule" mechanism or go for
some dynamic pre-processing of profiles. That way we can turn the
general purpose "vCard" mimeprofile into a "vCard-Evolution" mimeprofile
which matches exactly what Evolution supports.
--
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.
_______________________________________________
os-libsynthesis mailing list
os-libsynthesis@synthesis.ch
http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
