---- Reported by email@example.com 2010-04-26 19:54:26 +0000 ----
This is from http://bugzilla.moblin.org/show_bug.cgi?id=10462
Description From pohly 2010-04-04 12:48:57 PST (-) [reply]
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
- Evolution shows email as "other" (might be right, there was no
- 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.
------- Comment #1 From pohly 2010-04-09 09:22:38 PST (-) [reply] -------
As a short term solution I disabled the extensions in the config. Now we can
treat this issue as an enhancement request.
Here's an idea I had. We could add a new "static-rule" XML parameter with the
- can appear in any XML element
- value are boolean expressions with ! | & and brackets, with
plain words as atoms, for example: KDE | !EVOLUTION
- a backend can produce new profiles by giving the original profile ("vCard"),
the new name ("vCard-Evolution:") and which atoms are to be set (EVOLUTION)
- an XML parser does that by iterating over all elements and removing those
for which "static-rule" is false
- we must remove the parameter in the config passed to the engine or extend
the engine to ignore it
------- Comment #2 From pohly 2010-04-20 05:38:07 PST (-) [reply] -------
Lukas explained this in an email:
> 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?
X-Synthesis-RefX was introduced a while ago for the Windows Mobile clients as a
handle for servers to keep multiple TELs, ADRs, URLs, EMAILs of the same TYPE
apart. As Windows Mobile has fixed fields (and no dynamically expandable arrays
like iPhone or Symbian), the RefX are just hard-wired enumerations of equally
typed fields, like HOME 1, HOME 2 etc. This is something we added mainly for
Oracle as they wanted control of which TEL goes to what field.
On the iPhone, multiple occurrences of ADR/TEL/URL/EMAIL are dynamic, but have
a persistent ID (not just an index) that allows referencing them later. So I
exposed them using the already introduced X-Synthesis-RefX syntax. Having these
IDs allows full fine grain control over what gets updated, but a full blown
server side implementation for this would need a per-device mapping table. With
a server that just stores the X-properties along with the data it works as
well, however only as long only one device is synced (Oracle does neither).
> Same for ADR_STREET_LABEL, which would show up as X-CustomLabel-<label>.
This is iPhone only (so far), and exposes the custom labels (which don't map to
> 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.
We don't have a full implementation (with the per-device ID mapping) in the
server (altough it would be possible with some extra scripting). The IOT server
on www.synthesis.ch just stores custom labels, if present, along with the
TEL/EMAIL/ADR/URL, but ignores the X-Synthesis-RefX.
--- Bug imported by firstname.lastname@example.org 2012-08-19 20:56 UTC ---
This bug was previously known as _bug_ 1368 at https://bugs.meego.com/show_bug.cgi?id=1368
Unknown platform unknown. Setting to default platform "".
Unknown operating system unknown. Setting to default OS "".
-- GitLab Migration Automatic Message --
This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.
You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/SyncEvolution/libsynthesis/issues/2.