OK, still working through these two messages, but first, the concepts:
*Context*: a service that can host one or more *Sources*.
*Source*: a folder hosted in a *Context* of a certain type (calendar or
contacts).
*Config*: can be a *Source Config* or a *Sync Config*.
*Source Config*: a *Source* hosted in a *Context* with added properties
(key-value pairs)
*Sync Config*: a pair of one local and one or more remote *Source
Configs* hosted on the *same* *Context* tied together, with added
properties (key-value pairs)
Am I getting close yet?
On 02/04/2014 13:20:42, "Patrick Ohly" <[email protected]> wrote:
On Wed, 2014-04-02 at 11:57 +0100, Graham Cobb wrote:
On 02/04/14 09:49, Emiliano Heyns wrote:
> Setting up the actual sync (exchange-local so far -- on to google
once I
> understand this) is still mystifying. This is what works (for
Exchange
> <-> Local), but I have no idea why:
Part of the confusion may be understanding the need for two sides to
the
sync. Here is my best go at explaining what is going on.
That's all correct. I just have one minor comment: the SyncEvolution
terminology for @Local is "context", not "source config". A source
config is for one particular source (for example, "addressbook" in
context "@local"). Your usage of "source config" is more like
"configuration of a certain set of sources", which is indeed what a
context does. In addition, it has peer configs using that set of
sources.
[By the way, Patrick, I think things would be easier to understand if
it
was possible to setup the local syncUrl as "local:://peer@source" and
"peer@source" would be the corresponding sync config instead of the
special name target-config@source. It may be there is some reason not
to do that, but I have always thought of target-config as a horrible
hack]
Reusing the existing concepts for local sync was indeed a shortcut. The
reason for using the fixed name "target-config" were:
1. I couldn't think of a situation where a user might have more
than one such peer config in a context. The way it stands now,
a
user doesn't need to choose a name.
2. A source instantiated in context "@foo" for item operations
knows that it can find additional settings (loglevel,
username/password) in the "target-config@foo". If we removed
the
fixed name, the user would have to be explicit about it, i.e.
"--print-items @foo addressbook" would have to become
"--print-items peer@foo addressbook".
It might very well be that you are right and removing the implicit
convention in favor of more explicit actions by the user would be
easier
to understand. Any thoughts?
We could change it, perhaps by allowing both: allow the explicit
"local:://peer@source" in addition to "local://@source" with the
implicit peer=target-config, and let sources only fall back to
"target-config" if nothing was given explicitly.
--
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
