388f72b369
The meaning of "type" was horribly complex and had effects on the backend and the peer. It was impossible to specify the sync format to be used for a specific peer independently of the local backend and its format, so adding a peer to a context broke the context configuration (BMC #1023). This is now fixed by splitting "type" into four independent properties: - backend = plugin which interfaces with the data - databaseFormat = data format used inside backend, only relevant for file backend - syncFormat = data format preferred when talking to peer - forceSyncFormat = disable format auto-negotiation, use preferred format With that split, it is now possible to specify the format in which the file backend stores items independently of the format in which they are exchanged with the peer. Old configurations with "type" can still be read. The values specified inside it are transparently mapped to the new properties. Command line and D-Bus API users will only see the new properties. The command line tool still accepts "type" as an alias for the four new properties. Using that has the same disadvantage as before: it will modify the context even if only modifying the peer was intended. The D-Bus API accepts only the new properties. Clients using "type" must be adapted to the new property names. Clients not using that continue to run unchanged. Writing into the configuration requires a migration of the peer config *and* the context in which it is defined. That is necessary because the new semantic (independent database format) cannot be stored in the old format. The migration is handled by rewriting first the context, then all peers defined inside it. Other user-visible changes: - updated help texts - the canonical "backend" value for the file backend is just "file" instead of the long "Files in one directory", which is now an alias (used to be the other way around); done because "type = file" was expanded to the long name, which was a bit unexpected and showed how unintuitive the long name is Internal changes: - getMimeVersion() is still present, although it hasn't been used for a long time; FileSyncSource::getMimeVersion() now derives the version from the supported Mime types, in case that the function will be needed again in the future - setSourceType() with string as argument was replaced with one taking a SourceType instance; to emulate the old behavior if desired, construct SourceType from an old-style string - ConfigProperty methods need to be virtual so that derived classes like SourceBackendConfigProperty can generate content at runtime (a recent commit broke that feature) - File templates were stripped down to the essential properties, with "type" replaced by the per-peer "syncFormat". "type" would still have been accepted (so it is not necessary to adapt syncevo-phone-config right away), but has the original disadvantage of modifying "backend" and "databaseFormat". |
||
|---|---|---|
| .. | ||
| clients | ||
| servers | ||
| README | ||
The configuration templates in this directory are *not* complete and therefore not suitable for copying them directly in a .config directory. They contain only those properties which are different for a certain peer compared to the built-in default values. They are used by the SyncEvolution binaries to create complete configurations.