On 25.04.2014, at 21:47, Patrick Ohly <patrick.ohly(a)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
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
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