9db07a66a7
Sending the X-EVOLUTION-UI-SLOT parameter to a Nokia phone when updating an existing contact confuses the phone such that it drops the phone number or email that had the parameter; the initial import was okay. Reported for Nokia N81, E72, root-caused on a N97 mini. Sending the X-EVOLUTION-UI-SLOT has very little value except when talking to another SyncEvolution instance. All other SyncML peers are expected to simply ignore the parameter, so there is no point in sending it in the first place. This is the solution implemented in this patch. A "rule" parameter of the <parameter> element that defines X-EVOLUTION-UI-SLOT declares that the parameter is to be ignored when parsing or generating vCards, except when the peer is known to be SyncEvolution. A remote peer is detected by the new 00_syncevolution.xml remote rule. Locally, the parameter needs to be enabled when talking to Evolution (evolution.xml) or to files which can also store the parameter (all.xml). The later case is important for a SyncEvolution HTTP server with file storage. Running "./client-test Client::Sync::vcard30::testItems" against such a SyncEvolution server confirmed that without all.xml, the X-EVOLUTION-UI-SLOT got lost, which also confirms that the rule mechanism works. |
||
|---|---|---|
| .. | ||
| datatypes | ||
| debug | ||
| remoterules | ||
| scripting | ||
| Makefile.am | ||
| README | ||
| syncevolution.xml | ||
| update-samples.pl | ||
The sample configs contain common elements (datatypes, scripts, remote rules, debug settings) which are maintained as separate files in the corresponding directories. When modifying those common elements, run "update-samples.pl" in this directory to update the sample configs. The complete samples are under version control for several reasons: 1. avoid dependency on Perl unless common elements need to be updated 2. effect of changes on complete config show up in patches 3. the file layout and unshared parts (<client> and <server>) are determined by the sample configs The naming of common elements determines the order in which they get inserted. Files not ending in .xml are ignored. Elements that only apply to a client or server are stored in the corresponding sub directories, while the shared elements are in the "debug/scripting/datatypes/remoterules". It is a somewhat subjective choice which elements are stored in one file and which ones are split up. The three elements of a datatype definition (field list, profile, datatype) where split up because there might be multiple different profiles using the same field list and some users of these files might want to replace the default one.