On 13.09.2012 16:49:12, Patrick Ohly wrote:
On Thu, 2012-09-13 at 16:19 +0600, Ildar Mulyukov wrote:
> 1. SyncML server can work with multiple number of clients, right?
> Is this true for the SyncEvo server role too?
Yes. Each peer config is tied to one SyncML client. You can have as
many
peer configs as you want. They can (and usually do) share the same
databases, but don't have to. One could also define different contexts
with disjunct definitions of local databases, then add a clients to
that
context which has the right data. Or add the clients to a context
which
has multiple databases and configure the clients to use the database
they want via their URI config.
/me has mind overheat :)
That is why I tagged SyncEvo design complicated!
I still need some time to sort out all these terms. I suggest that a
simple hierarchy (what contains what) would make the picture more
clear. I'll try to draw this out when I finish "sorting" job.
> 2. Having SyncEvo capable to act as a server and client, it is
possible
> to have a local SyncEvo server sync with a remote server, probably
> through and intermediate local database with e.g. backend=file ?
Yes. Indeed you need a local database for that. SyncEvolution is not a
SyncML proxy which forwards traffic from a SyncML client to a SyncML
server - I'm not sure such a thing would even make sense. Proxying the
HTTP requests would work better.
Ok. Putting away the proxy issue, next question:
3. Getting back to the design question, does the use of syncevo like
this look reasonable to you?  (attached)
Advantages of this would be:
1. You always have a Syncing engine at hand. This may be THE ONE
UNIVERSAL ANSWER to the question of conflict resolving.
2. No need in target-configs for non-SyncML cases like ActiveSync.
Patrick?
--
Ildar Mulyukov, free SW designer/programmer
================================================
email: ildar(a)users.sourceforge.net
blog:
http://johan-notes.blogspot.com/
ALT Linux Sisyphus
================================================