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.