Hello Patrick, On 25.04.2014, at 21:47, Patrick Ohly <patrick.o...@intel.com> wrote:
> [...] > > The bigger problem will be on the Evolution side. I don't see how I can > teach libsynthesis that a IMPP entry whose protocol (encoded as part of > the value!) is xmpp maps to X-JABBER. I see no direct way either. > Should I keep the traditional JABBER_HANDLE array and move entries back > and forth between it and the IMPP array? This could be done with > incoming/outgoing resp. afterread/beforewrite scripts. I guess that's the way to go. In particular, I added the incoming/outgoing scripts on the datatypes (looong time ago :-) for very similar problems, after realizing that the formerly pure declarative way to describe vCard/Calendar types was getting more and more complex and still not catching all cases at hand. In the libsynthesis based iOS clients, incoming/outgoing scripts are used a lot for exactly this type of normalizing data for the internal representation. No surprise that the scripting engine got regex support then... 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. So I'd think doing this in incoming/outgoing scripts would be better. As you said, JABBER_HANDLE would need to be kept as a temporary storage area for the parser to put X-JABBER values into, but the IMPP array would be the actual internal representation for the data. 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
