[SyncEvolution] new configuration layout + migrating configs

Hello! The new configuration layout design document describes an approach how old configurations could be migrated into the new layout with shared properties: http://syncevolution.org/development/configuration-handling The scheme is complex, does not work in all cases, and hasn't been implemented yet. I wonder whether it is worth the effort at all. Conceptually, migration of two old configs into the same context does not work seamlessly. The old configs had two different deviceId values, but in the same context they'll share one property. The current implementation of "syncevolution --migrate" will preserve the first deviceId that gets migrated and then ignore any following ones, leading to slow syncs for these migrated configs. This is slightly better than overwriting the deviceId, because that would force slow syncs for all already migrated peers. A single config could be migrated without problems. This was meant to be done automatically for GUI user. It hasn't been implemented yet. When would be a good time for this - when running a sync? The advantage of automatic conversion is fairly limited, though, at the moment. Because the logdir settings are all the same, new functionality like scanning for sessions of any peer should work also without migrating the config. Checking whether a migration can be done without problems is hard. It would have to check whether any existing shared properties would be modified. A simpler check would be to check that the new context doesn't exist, but that is too coarse. When two peers share the same context, currently one of them can be migrated (= rewritten, which updates the property comments) without problems. A context check would prevent this. My conclusion is that a simple check is useful for automatic migration (which should never cause harm) and not needed for --migrate (which needs a warning in the documentation). Automatic migration should be limited to the D-Bus server and thus GUI users. Command line users can use the --migrate option. Agreed? Speaking of documentation, this needs to be overhauled to cover the new semantic of the "server" name. It's no longer necessarily a server and may contain a context. I suggest to replace it with "config name" or simply "config", with an explanation what that means. Should we do the same in our source code? Some code passes around a "server" string, but in reality it is now also a "config". This will be a massive patch based on lots of automated search/replace. Advantage: conceptually clean code. Disadvantage: high code churn. Thoughts? -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter.