Hello Patrick, On 20.07.2011, at 18:10, Patrick Ohly wrote:
> I am adding support for PHOTO;VALUE=uri to SyncEvolution. A > straight-forward solution is this: > > <field name="PHOTO" type="blob" compare="never" merge="fillempty"/> > <field name="PHOTO_TYPE" type="integer" compare="never" > merge="fillempty"/> > <field name="PHOTO_VALUE" type="string" compare="never" > merge="fillempty"/> > > But... what if one contact has PHOTO:<binary data> and gets merged with > a contact that has PHOTO;VALUE=uri:http://foo.bar? > > My fear is that I'll end up with PHOTO;VALUE=uri:<binary data>, because > of the "fillempty" merge mode for PHOTO_VALUE. A similar problem also > exists for PHOTO_TYPE. > > What I would need is a "fillempty" for PHOTO and a > "copy-if-photo-was-copied" for the other two fields. Basically, this problem exists with all multi-valued properties, like TEL;TYPE=xx:. It's true that the fillempty mechanism does not properly handle these cases. The problem is that the grouping information is defined in the profile, but merging takes place on the fieldlist level. Sometimes I was thinking of creating field group definitions on the fieldlist level. But then I came to the conclusion that many real world cases demand more than just grouping anyway, and that was when the <incomingscript> and <outgoingscript> were born. This is just more flexible, and often also easier to understand what's going on. Script were a relatively late addition to libsynthesis, so there's a lot of quite complex hard-coded mapping machinery available, but if I had scripts from the beginning, I'd probably done more with scripts and less with complex mapping features. > I don't think that exists, so my current approach is to have an incoming > script which ensures that the PHOTO_VALUE is never empty (sets "binary" > if unset) and an outgoing script which strips it again (to emulate > current behavior). I'd agree this is the way to go. > It's not working 100% correctly because for field > lists populated with PARSETEXTWITHPROFILE() the incoming script is not > executed. Maybe we should add an option to PARSETEXTWITHPROFILE() and MAKETEXTWITHPROFILE() to have the scripts called? > Am I on the right track or should I simply ignore the problem? In fact, ignore is what I did so far :-( I've seen the possibility for wrong merges as you do, but never encountered them in the field as a problem so far. Best Regards, Lukas Zeller _______________________________________________ os-libsynthesis mailing list os-libsynthesis@synthesis.ch http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
