1:18 p.m.
Hello!
We need to come to some conclusion on the proper handling of the super
datastore configuration. Currently we have code in "master" which
already implements a super datastore for the "calendar+todo" use case
(OVI.com, phone), but my understanding is that it will break unless
configured correctly.
See below for my open questions, plus some additional comments.
On Tue, 2009-12-08 at 10:54 +0100, Patrick Ohly wrote:
On Tue, 2009-12-08 at 08:57 +0000, Chen, Congwu wrote:
> Patrick wrote:
> >We are the server, the phone is the client. Do you mean client here?
> Correct.
> >Care to explain? I don't see why or where the todo items would be
> >rejected.
> This is done by synthesis, during subdatastore dispatching, if it failed to
> find a corresponding backend, it rejects.
But we are not yet configuring the Synthesis engine like this, do we? At
the moment, whenever the "super" source is active, it always dispatches
to both "calendar" and "todo", doesn't it?
> >> >The semantic that we export to the user then becomes:
> >> > * when you have a virtual data source configured, then
activating
> >> > any of individual data sources or the virtual data source
> >> > includes all data in the virtual data source in the sync
session
> >> > * all of these sources must use the same sync mode
> >> >
> >> I would also like to support syncing only calendar or todo, if my above
> >comments
> >> made sense.
> >
> >Even if we can get it to work, is it guaranteed that the two peers
> >remain in sync?
> >I had asked Lukas that on the Synthesis mailing list. The Synthesis
> >engine is smart enough to distinguish between temporary and final status
> >codes, but a) many servers always sent a 500 status code, regardless
> >what their problem was and b) clients do not check the exact status
> >code.
> >
> That maybe the problem... The configuration of 'super', 'calendar'
'todo' duplicates
> a lot, I am thinking we may come up with some kind of sharing config node to keep
> them in sync.
That would be hard to implement. The config node sharing doesn't know
anything about such semantic relationships between sources.
I'd prefer to leave the config system as it is and clearly document (and
check) what is required for consistency.
I've previously argued that running something like "syncevolution ...
calendar" in a configuration that has a "calendar+todo" super datastore
should implicitly activate the "calendar+todo" source. I'm no longer
sure whether that is a good idea, because we cannot reliably exclude the
"todo" part from the sync and enable it again later.
That leaves "syncevolution ... calendar+todo". This is valid, but it
means that the core is going to called with both "calendar" and
"todo"
disabled, because the front end is too dumb (and should remain dumb!) to
know that "calendar+todo" depends on them.
To handle this, I think we should declare that the "sync" property of
sources which are merged into a super datastore are ignored. That
setting must be taken from the super datastore config. Inconsistent
settings are not an error, because the "syncevolution ... calendar+todo"
command line invocation will lead to such an "inconsistent" config.
A config for a peer with a super datastore should not set "uri"
properties for the sub-datastores. This will automatically have the
effect that the sync-UI will show those sub-datastores as greyed-out and
prevent setting their "sync" mode.
--
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.