On Tue, 2012-10-09 at 12:05 +0600, Ildar Mulyukov wrote:
Proposal #2. Turn peer configuration into just-another-source kind.
(As being quite new to SyncEvo) I don't see a big difference between
"source" and "peer" configurations. At least, the difference
bigger then for example the difference between supported sources
backends. Even more, some of the sources look more like remote peers,
but only with another protocol (CalDAV and ActiveSync come to mind).
Peers are just sources, special in one thing: they are SyncML-servers.
There is another difference: a peer has multiple sources. A source only
has one. You suggest to remove that difference and also the per-peer
properties of a source, right?
How would the user request a sync of all sources configured for a
specific peer ("syncevolution funambol", for example)?
Accepting this change would bring us to a simpler picture where every
context has just a set of sources each having:
1. the database/databases property
2. the sync mode, which clearly defines data flow permissions, e.g. rw,
read-only, write-only, none
3. their whitelist and/or blacklist of sources to sync with. E.g. I
want my phone (backend=obex) to sync with the local addressbook
(backend=eds), but not with Google (backend=SyncML-server).
Where do you put the username/password that is needed to access a peer?
Duplicate it for each source in that peer or configure credentials
separately (similar to
Where and how is the connection between two sources specified? Where are
the settings related to that connection (loglevel, data direction)? It
is possible to have sources A, B, C, D connected like this: A<->B,
A single value for connection properties in a source will not work,
because A and C both have more than one.
Depending on types of sources to be synced, SyncEvo may decide to use
embedded SyncML-server or source's server capability if backend is
And drop the cryptic target-config.
Just my fantasy, but what do you think?
I think it may be possible to get rid of "target-config" but the
concept in general seems necessary and useful.
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.