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