On 13.09.2012 19:04:05, Patrick Ohly wrote:
On Thu, 2012-09-13 at 18:08 +0600, Ildar Mulyukov wrote:
> 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 could have kept it simple by describing only one option. Would that
have been better?

No! I just couldn't dodge writing that :)

> 3. Getting back to the design question, does the use of syncevo like
> this look reasonable to you? ![.](SyncEvo graph.png) (attached)

I don't understand what the diagram is meant to tell me. Do the arrows
mean data flow? Then in that diagram, changes made by a phone are never
sent back to EDS.

No, that was kinda "what connects to what" thing. That was just a sketch, not a precise picture.

Also, why is it necessary to have the two additional databases involved
("file backend" + "intermediate database")?

It is not if you say so. You know this better then anyone. And I'm just learning.

>     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.

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...)

> 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.

Sorry that my posts are too lame. I hope they will lead me (and probably someone else) to better understanding of SyncEvo.

Best 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

Reply via email to