On Tue, 2009-09-15 at 02:46 +0100, Zhu, Yongsheng wrote:
> > 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?
The disadvantages of the old scheme are:
* Finding all old sessions involving a certain local data source
is harder.
* Settings are duplicated.
* When we as a SyncML client are contacted by a server for the
first time, it is unclear which local source and logging
configuration we are supposed to use.
I'm wondering - do I overestimate the disadvantages of the old scheme?
Should we stick to it and work around its limitations?
> 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?
Yes. But this is unlikely, isn't it?
--
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
