2:12 a.m.
On Mon, 14 Dec 2009, Ohly, Patrick wrote:
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?
Yes, but it
is achieveable, just generating the subdatastore that is actually
active.
This was the idea before, but you have pointed rejecting the sync items can not
gurantee the phone understands this and may casuse the peers out of sync.
That's possible, so "enabling always both sync source" (treating calendar
and
todo always as a single sync source) seems the right position.
>
> > >> >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'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.
I think we will
always export 'calendar+todo' as a whole to user. Syncing part
of the syncsource should not be allowed.
This also means testing a superdatastore, only need to activate the
superdatastore source (which will automatically activate all sub datastores).
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.
Ignoring duplicated properties is prefered. So 'sync' and
'uri'should be
set in the virtual datasource, the sub datasource should take these two
properties as ignored. No inconsistence check is needed for the two.
To implement this, when instatiating a virtual datasource, it will cause
all sub datasources be enabled the same time and the 'sync' and 'uri'
property
is set temporarily from the value in virtual datasource.
There is still one property left need some consistence check: 'type'. It cannot
be simply merged, because a sub-datastore may still use it to identify it's
specific backend. However the 'format' part must be exactly the same for all
subdatastores and the virtual datastore.
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.
--
Regards,
Chen Congwu
Moblin China Development