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.
_______________________________________________
SyncEvolution mailing list
[email protected]
http://lists.syncevolution.org/listinfo/syncevolution
