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.