On Fr, 2011-09-09 at 17:29 +0200, Murray Cumming wrote: > On Fri, 2011-09-09 at 17:17 +0200, Patrick Ohly wrote: > > On Fr, 2011-09-09 at 16:20 +0200, Murray Cumming wrote: > > > On Fri, 2011-09-02 at 10:25 +0200, Patrick Ohly wrote: > > > > On Fr, 2011-09-02 at 09:56 +0200, Murray Cumming wrote: > > > > > Is there any reason to refer to "peers" here instead of "services"? > > > > > http://syncevolution.org/documentation/compatibility > > > > > > > > Peers also includes things like mobile phones, services doesn't. That's > > > > the main reason. Feel free to make this more readable. > > > > > > > > That such peers work is not documented well (ehem, at all?) on the page, > > > > though. There is only the Wiki pages side bar which lists pages tagged > > > > appropriately. > > > > > > And what does it mean by "indirectly" synchronizing data? Is that > > > something people are likely to be interested in? > > > > What I meant are combinations like "Evolution <SyncEvolution> Google > > <SyncML/ActiveSync> 'some mobile phone or Windows PC'". > > How can SyncEvolution influence what happens after Google in that > situation?
In some rare cases it might be able to do something by sending data differently. Or if it knew that the phone in this example dropped certain fields and thus Google incorrectly attempts to remove them later on when forwarding an update, then SyncEvolution could preserve that data locally. SyncEvolution already does that for things it knows that Google itself doesn't support. But this way lies madness... > Likewise how can Syncevolution be influenced by the > SyncML/ActiveSync bit when going in the other direction? I can imagine > it triggering certain side-effects, but are they a big deal? Data loss is a big deal and user's concern about it are justified. SyncEvolution goes a long way to make it as safe as possible to experiment with syncing (see the recent story from Ross Vandegrift about restoring from SyncEvolution's backup after a mishap involving the sync direction), but it cannot cover everything. > > The page is only > > about the compatibility between peers that SyncEvolution directly talks > > to (Google in this example), but not about the involved parties that > > SyncEvolution doesn't even know about (the Windows PC). > > > > Such combinations are indeed relevant for users, but documenting them > > would be a lot of testing and writing work. Therefore the web page > > intentionally focuses on the part that involves SyncEvolution. That's > > what the first paragraph is supposed to mean. > > I guess that as > a) The combinations haven't been tested throughly. > b) They never will be. > c) We don't even mention known problems, let alone > mention the (hopefully more) known successes. > c) When something doesn't work, it's a bug and should > just be filed rather than just documented. OK, so > some things can't be fixed by SyncEvolution, but > again, that's not really SyncEvolution's problem. > then it would be best to just not mention it. Or just mention that other > parts of the synchronization situation could trigger problems. The overall goal with syncevolution.org was to give users an idea of what is known to work and what isn't. In this case the answer for certain cases is "we don't know" - I still find it better to spell that non-answer out somewhere, ideally somewhere where the user looks for it, instead of having him search the whole site for an answer that can't be found. -- 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
