On Do, 2013-11-21 at 11:51 +0530, Sachin Gupta wrote: > Hi Patrick, > > A query. > In the folder /usr/share/syncevolution i found a file 02google-contacts.xml > What is this file used for? In a sample exchange between client and > server, i found the xml being dumped which seemed to be the same as > this one. > But the xmls being dumped were different. > > Also, This has a tag "overridedevinf". Is this for overriding the > devinf information in the xml above?
It does the reverse of what you want to do (at least as far as I understand it): Google's SyncML server did not include CtCap information in its DevInf. The 02google-contacts.xml adds that information by hard-coding it on the client side. In other words, you can feed arbitrary DevInf for the server into a SyncEvolution client, but you cannot make the client send different DevInf. >From the commits: commit 17337d46ce299846335a26041199459cac95cdc0 Author: Patrick Ohly <[email protected]> Date: Wed Jun 15 15:55:59 2011 +0200 Google Contacts: add CtCap information (BMC #15029) The CtCap information is necessary for preserving fields not supported by the Google SyncML server. It depends on the "overridedevinf" patches for libsynthesis, currently under review. commit 62df728b87da358b497696ced0500ff221ea0979 Author: Patrick Ohly <[email protected]> Date: Wed Jun 15 12:24:17 2011 +0200 remote rules: added OverrideDevInf Many SyncML servers send DevInf without CtCap inside. For those servers, the engine (often incorrectly) has to assume that they support all fields. This patch adds a configuration element "OverrideDevInf" which helps to address this problem. It may occur in a "RemoteRule". Once that rule matches a DevInf sent by a peer, processing of CtCap continues with the CtCap element of the DevInf inside the remote rule. This allows adding and overriding the CtCap from a peer. "OverrideDevInf" must contain a complete DevInf, although right now only the CtCap inside it really matters. This approach has the advantage that it can reuse the existing and somewhat documented CtCap format for describing capabilities. The downside is that not everything can be encoded in that format, for example, how many components of the ORG field are supported. A possible solution for that is to extend the format in a way that only the Synthesis engine understand and/or standardize such extensions. Right now the "OverrideDevInf" content is only parsed when needed. Beware that syntax errors will only be found when using the rule! -- 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. _______________________________________________ SyncEvolution mailing list [email protected] https://lists.syncevolution.org/mailman/listinfo/syncevolution
