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?
> > 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)
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.
Also, why is it necessary to have the two additional databases involved
("file backend" + "intermediate database")?
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).
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?
--
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.