Hello! As mentioned before, the new configuration layout with shared properties requires a classification of which properties are shared between peers: http://syncevolution.org/development/configuration-handling I've updated the classification slightly today: * loglevel, printChanges, IconURI are now per-peer properties (were shared before): IconURI clearly belongs to the peer, loglevel and printChanges could be shared. I made them per-peer settings because is conceivable that one might want to have different settings (high loglevel for one peer while debugging it, printing of changes off for peers where we act as server in the background) * "sync" per peer instead of shared; again, this should have been per-peer from the start * "type" per peer, because it contains per-peer parts (the preferred data format) The "type" is problematic. It selects both the backend (address book/calendar/Evolution Address Book/etc.) and the data format (iCalendar 2.0/vCalendar 1.0/both/...). This hack seemed like a good idea because a) it avoided introducing another property and b) the backend can be deduced from the data format ("text/vcard" => backend which provides contacts, use vCard 3.0). I'm not entirely sure how to deal with it yet. Perhaps introduce a shared "type" property and a separate, per-peer "dataFormat" property which are presented in the view as one "type"? That makes it impossible to set inconsistent values via the APIs and keeps the rest of the code as it is now. -- 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.