On Fri, 2012-09-14 at 12:06 +0600, Ildar Mulyukov wrote: > > Each time SyncEvolution does a sync, there is a syncing engine > > involved. > > The only difference is whether SyncEvolution acts as SyncML server > or > > lets another server do that work (SyncEvolution acting as SyncML > > client). > > That's the idea: a user can always resolve conflicts locally, not > relying on how a remote server will do that. (If it's ever a problem. > I think I've read it somewhere...)
It can be, so I agree that such a change could be useful. However, making it mandatory would not be the right thing for some cases and users (those who trust their server and want to use SyncEvolution as just a normal SyncML client). Therefore implementing that mode would just make SyncEvolution *more* complex ;-} Removing features to make SyncEvolution simpler is tricky. The justification for working on it on company time is the usage of SyncEvolution in special systems (a phone, a tablet, IVI head unit), in which case the complexity is hidden and not visible to the user. I cannot remove features or modes of operation which are required for those setups. Making SyncEvolution nicer to use by open source users via the command line is always something that has lower priority from that perspective. It's something that I do because that's how I use the tool myself and because it is required to get the new features into the hands of users who can provide feedback (and bug reports), but that's it. > > > 2. No need in target-configs for non-SyncML cases like > > ActiveSync. > > > > If you have just one config for non-SyncML, then where is the location > > and format of the local database configured? > > No, I meant something different. No need to have a _special_ _type_ of > config: *target-config*, which complicates understanding. This has been discussed (well, documented) on the list when local syncing was designed and implemented (linked to in the "developer" section of syncevolution.org, in case that you haven't seen it): http://thread.gmane.org/gmane.comp.mobile.syncevolution/1543 http://thread.gmane.org/gmane.comp.mobile.syncevolution/2177 I agree that the concept can be a bit hard to understand. But from an architecture perspective I consider it pretty clean. For example, implementing the PBAP caching for IVI based on the concept is straight-forward. It avoids data duplication in the configs and avoids special cases for operations like --print-databases, --import/export, etc. The reason why I am unhappy with it is that sometimes it can be hard to understand which config options really have an effect. For example, where does "preventSlowSync" need to be set (in the sync config, the in the target-config gets ignored), are log levels independent (yes, they are). This is an area that could be documented better and probably needs to be cleaned up to become consistent. -- 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
