On Sun, 2014-07-27 at 08:03 +0005, Khurshid Alam wrote:
> Hi Patrick,
> 
> On Fri, Jul 25, 2014 at 8:35 PM, Patrick Ohly <[email protected]>
> wrote:
> > On Fri, 2014-05-23 at 13:02 +0200, Patrick Ohly wrote: 
> >         Let's revive this mail thread once more. The goal is to
> >         agree on a change of the README.rst, in particular in the
> >         terminology section, and then make the necessary code
> >         changes to match that change. I don't want to make code
> >         changes unless other developers or users agree that the
> >         changes are an improvement, so please provide feedback.
> 
> I did like the new terminology. Its much better than previous one.
> Easy to understand. Also old terminology still works as fallback which
> is good.

Thanks for the heads up.

> One thing I always struggle, is to initiate a sync between two
> evolution databases defined in different contexts (without running
> syncevolution http server).

You'll need the local sync feature for that.

> For example,  lets say I have two calendars on evolution; Work &
> Personal. And they are defined like this (with new terminology):
> 
> 
> syncevolution --configure --template none backend=evolution-calendar
> database=Work @Local workcal
> 
> 
> syncevolution --configure --template none backend=evolution-calendar
> database=Personal @EDS personalcal
> 
> 
> How to initiate a sync between them?

SyncEvolution can only sync between peers. The peers are where
SyncEvolution maintains meta data relevant for running multiple,
incremental syncs. By definition, that data is not in the databases (and
can't be, because most databases simply have no way of storing it).

So to initiate a sync of these two databases, one needs two peers (or
for each DB).

>  Which one will act as client & which one as server?

It doesn't matter in this case. Usually it is more efficient to use the
DB which can be accessed more quickly on the server side.

> Is it necessary to define them in different contexts(@Local, @EDS) at
> all? What if both are defined within @Local? Is it, then, possible to
> initiate a sync between them?

It is no longer necessary to define them in different contexts. It used
to be, but I also already came to the conclusion that this was
unnecessarily restrictive.

Coming back to the example, here's how a two-way sync of these two DBs
can be set up:

 syncevolution --configure --template none sync=two-way target-config@EDS 
personalcal
 syncevolution --configure --template SyncEvolution_Client syncURL=local://@EDS 
sync=two-way uri=personalcal calendars@Local workcal
 syncevolution --sync slow calendars
 syncevolution calendars # incremental sync



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



_______________________________________________
SyncEvolution mailing list
[email protected]
https://lists.syncevolution.org/mailman/listinfo/syncevolution

Reply via email to