On 26.04.2014, at 21:11, Patrick Ohly <patrick.o...@intel.com> wrote:
> On Sat, 2014-04-26 at 12:30 +0200, Lukas Zeller wrote: >> The afterread/beforewrite script could do such a conversion as well, >> however for normalizing data these are executed too late on the server >> side for normalized data to be used in slow sync matching, so it'll be >> more complicated to correctly match and merge records. > > What do you mean with that? The afterread script gets called after > reading and before using the field list, right? So whatever > transformation is necessary (for example, X-JABBER -> IMPP) can be done > in time before the engine processes the IMPP field. It's the opposite direction I was thinking about: Assuming you chose the IMPP array to internally represent jabber, and further assuming a sync with a peer that uses the X-JABBER format, incoming items would be parsed and compared with existing items (in a slow sync for example) without beforewritescript being run. So you'll compare/merge non-normalized items (those coming from the peer) with normalized ones (those coming from the database). This might not be relevant in the specific SyncEvolution case because of the vCard-based database backend, i.e. the fact that both ends are vCard representations of the data. But for a classical libsynthesis SyncML app with a ODBC or SQLite backend: incoming/outgoing scripts are the place to handle variations in the *representation* of the same data content in vCard, whereas afterread/beforwrite just implements the non-trivial parts of the 1:1 *mapping* of the internal data content to a database backend. Best Regards, Lukas
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ os-libsynthesis mailing list os-libsynthesis@synthesis.ch http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
