4:06 p.m.
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?  (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: ildar(a)users.sourceforge.net
blog: http://johan-notes.blogspot.com/
ALT Linux Sisyphus
================================================