On 14.09.2012 13:07:45, Patrick Ohly wrote:
On Fri, 2012-09-14 at 12:06 +0600, Ildar Mulyukov wrote:
> 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).
The whole proposition #3 was about a typical (and, maybe, default)
configuration for a user, not a mandatory. I was never thinking of
restricting the app to a particular use.
Therefore implementing that mode would just make SyncEvolution *more*
complex ;-}
Speaking of complexity: a software should be as simple as possible in
GUI (which is already done) and in concepts (for easy to understand),
but
can be as complex as needed to carry out all the functionality.
I propose to (possibly) raise internal complexity or internal
presentation as a price for simplifying of its presentation to a user.
Though I don't "see" the 100% of it: maybe instead of SyncEvo server in
the center there should be the Sync Engine (as in your presentation
gran-canaria-desktop-summit.ppt)
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.
Removing features is acceptable if there's a better solution to achieve
the goal (possible with auxiliary tool). I didn't intend any.
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'm on the way reading it.
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.
I come to think that it's not the architecture is complicated, but its
description and term set.
I'm still thinking of making a hint sheet of what in SyncEvo contains
what and how many (optional, mandatory, multiple etc.). It would
probably have a picture with terms and correlating folders under (an
example) ~/.config/syncevolution/
Regards,
--
Ildar Mulyukov, free SW designer/programmer
================================================
email: [email protected]
blog: http://johan-notes.blogspot.com/
ALT Linux Sisyphus
================================================
_______________________________________________
SyncEvolution mailing list
[email protected]
http://lists.syncevolution.org/listinfo/syncevolution
