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.

Emile

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
operations:
https://syncevolution.org/wiki/item-operations

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.