Hello Patrick, time flies, and while I also spend some time organizing my new workplace, most of it gets still consumed by Apple's new Gadgets and OSes (clearly one of the cash cows in our business, so that'd nothing I can neglect too much).
On Apr 7, 2010, at 14:45 , Patrick Ohly wrote: > 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? 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 a TYPE). > 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. > Third, are there perhaps other clients which get confused by these > extensions? At least ScheduleWorld might preserve them (not entirely > sure). I haven't heard of that yet, but clients of the Moto-Vx quality level will probably crash on those... > 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. Why not? Is the enhanced rule mechanism not sufficient yet for this? If not, what is missing? > 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. I saw that you did that - I agree that for now this is probably the most compatible way without loosing much. > 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. Again - shouldn't the new rule mechanism support this already? You wouldn't need two complete profiles, only two different property definitions. Best Regards, Lukas Zeller (l...@synthesis.ch) - Synthesis AG, SyncML Solutions & Sustainable Software Concepts i...@synthesis.ch, http://www.synthesis.ch _______________________________________________ os-libsynthesis mailing list os-libsynthesis@synthesis.ch http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
