On Fri, 2012-10-12 at 18:07 +0200, Patrick Ohly wrote:
> 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 isn't
> > 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)?
You did get me thinking :-) I still believe that the "peer" concept is
needed. However, its current implementation with one syncURL per peer is
too limited. It does not cover the case where syncing with one logical
peer involves multiple different protocols, for example SyncML + CalDAV.
Google falls into that category. That's why we had to introduce the ugly
"Google Contacts" and "Google Calendar" config templates.
It would be nice to fix this so that a peer defines all pairs of
sources, regardless of the protocol. It should still be possible to find
all pairs using the same protocol. This is relevant for syncing multiple
sources in a single SyncML session. OTOH, I am not sure how important
that optimization still is. It's actually a bit safer to sync one source
after the other, because then a malfunction only affects one source.
More important perhaps is that it must remain easy for the user to
configure the peer ("syncevolution --configure username=foo password=bar
memotoo").
--
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.
_______________________________________________
SyncEvolution mailing list
[email protected]
http://lists.syncevolution.org/listinfo/syncevolution
