I really do think my latest version captures the major concepts and the basic useful operations you can perform on them. It's laced with examples - if I got this iteration right, my next step is to rewrite the other how-tos in that vein.

More specifically, I think we need to converge, not diverge the terminology. I *have* diverted from the existing syncevolution terminology where I think they suggest commonality where there is none; perhaps the technical implementation of the configuration of target-config and sync config share code, but if my understanding of them is correct, their behavior is non-trivially different, and that I have reflected in new naming.

I am in no way specifically enamored by the new names I introduced, and I'll gladly swap them for others, but to have 3 sets of terms in play is not going to be helpful I think.


On Apr 16, 2014 6:42 PM, "Patrick Ohly" <patrick.ohly@intel.com> wrote:
On Wed, 2014-04-16 at 08:56 -0700, Todd Wilson wrote:
> I'll revise and expand my personal version of the README based on the
> comments you've given and repost. As I expected, there were several
> aspects of SyncEvolution I was only partially understanding, and I'll
> try to read through the documentation again with your comments in
> mind. Since my main conceptual misunderstanding concerned the
> relationship between databases and peers, could you give some extra
> explanation and perhaps examples to help me out?

I am not sure what additional explanation I can give beyond what was
already said in the mail threads and in the revised README.

Some examples can be found in the HOWTO on the item manipulation

This mostly just passes the required properties on the command line, but
all of the examples also work if you do a "--configure @somecontext
somesource" with the properties first and the just use "@somecontext
somesource" at the end of the command line.

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.