How about "source set configuration"? What all of the
config files
inside the "default" subdirectory have in common is that they are
related to the same set of local data sources.
I see. Ok for me.
In the new scheme, there is only one
"calendar/config.ini:evolutionSource", so the second invocation of
syncevolution changes the local data accessed by the normal
"scheduleworld" config, which is both unexpected and (in this special
case) undesirable.
So we combine these 2 calendar settings into one server config, what's the main
concern
to make this different from the old scheme?
For the scenario that there are many accounts for one server, the new scheme
remains the same as the old scheme to create one server config for each account, right?
Cheers,
Yongsheng
-----Original Message-----
From: Ohly, Patrick
Sent: Monday, September 14, 2009 7:47 PM
To: Zhu, Yongsheng
Cc: SyncEvolution
Subject: RE: [SyncEvolution] configuration + multiple peers
On Mon, 2009-09-14 at 05:30 +0100, Zhu, Yongsheng wrote:
> Therefore I suggest that we change our configuration layout.
Instead of
> a "server configuration" directory, we start with a "host
> configuration" (better names welcome!).
I'd like to use 'global configuration' or something else since it may
not only be 'host's settings'.
Suppose we add even "more global" settings:
.config/syncevolution/
config.ini
We need config.ini for the "active server", eh, "active peer"
setting
that is to be shared between sync-ui and Genesis.
I think "global configuration" is more suitable for these settings. In
that case we still need a better name for
the .config/syncevolution/default set of config files.
How about "source set configuration"? What all of the config files
inside the "default" subdirectory have in common is that they are
related to the same set of local data sources.
> Finally, the instructions for synchronizing multiple
ScheduleWorld calendars have to be updated. When setting up the second scheduleworld
config, the name of the "calendar" source is already in use and something
> else must be used to avoid overwriting the "evolutionsource"
> property in the existing source.
What does 'the second scheduleword config' mean?
The ScheduleWorld Wiki says (quoting from memory):
* create normal "scheduleworld" config
* create second config with "syncevolution --configure
--sync-property
syncURL=http://sync.scheduleworld.com/funambol/ds?cal=<id>
--source-property evolutionSource=<home calendar> --template
scheduleworld_home calendar
In the old scheme, this creates two server configs with different
syncURL and two different "calendar/config.ini" files, accessing
different local data.
In the new scheme, there is only one
"calendar/config.ini:evolutionSource", so the second invocation of
syncevolution changes the local data accessed by the normal
"scheduleworld" config, which is both unexpected and (in this special
case) undesirable.
I don't quite understand how to handle multiple configs for one
syncML server in new scheme.
The second configuration must use a different source name. Then the
normal "scheduleworld" config uses the default "calendar", and the
second "scheduleworld_home" the other.
Currently we don't have a good method of cloning source settings when
using the command line. Should we introduce a "--configure <server>
<source name>=<other source name>" syntax for this purpose?
If similar to previous, two configs are in 2 different directories,
so why existing the above issue you raise?
I hope it is more clear now.
--
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.