The Problem in 0.22, 0.3x --> 0.40
The conversion path is needed because OpenSync? builds the steps to go from one format to the other dynamically. Thus when OpenSync? receives a change, it builds the path to go from - let's say phone vcard21 to xmlformat - for working on the data (comparison, merge/demerge).
Then when it writes the change, it is triggered again to find the best conversion from xmlformat (which is the state our data are in at this point) to - lets say file for the file-sync - plugin.
The current (0.22, 0.3x - 0.40) is working somewhat but some part of what is working are by sheer luck (the ordering in which the format converter are registered is the most important factor right now in how it chooses it).
The current converter path builder is weird in that it chooses the first
registered if depth is even and the last if conversion path depth is not...
That's why vcard21 is choosed over vcard30 for file-sync storage : file-sync target format is depth 2 (xmlformat-contact-> formatX -> plain -> file) where formatX is any format that has a converter to plain and from xmlformat-contact. That is nearly every format converter. Though as the depth is even and vcard21 is the first so called converter confirming to those requirements it is choosen.
evo2-sync for example currently expects vcard30 for contacts (even though it ought to support both vcard21 and vcard30). And it has it because xmlformat to vcard is one depth conversion (and thus it grabs the last registered format): (xmlfortmat->formatX) where formatX is one of vcard21/vcard30.
So we don't have a handle on what format is choosen (for file-sync/evo2). Says we want file-sync to store as vcard30 see #827.
The Solution
First requirement : avoid the converter choosen to conversion depth relation. This can be done via adding a couple of new field id and neighbour_id to vertice and increminting those respectively at the vertice level and neighbour level. This will break assumption in plugins that relies on the current behaviour. See second point for a solution.
Second : reimplement format choice for the plugin. #827 .
