Hi Patrick, On Feb 11, 2010, at 13:44 , Patrick Ohly wrote:
> On Do, 2010-02-11 at 11:19 +0000, Lukas Zeller wrote: >> What would be needed is >> >> a) a user settings flag that indicates for some datastores that these >> must NOT be run on their own, but within the superdatastore. > > How about setting a special URI, like <none>? Because of the angle > brackets it cannot conflict with valid URIs. Sounds good, I'd only propose to use the superdatastore's name in angle brackets like <calendar>, so we can avoid a reverse search to find the matching superdatastore. >> b) An enhanced SelectProfile() in binfileimplclient.cpp, which would >> check that flag and figure out which superdatastore to instantiate in >> addition to the normal datastores. > > Is that really necessary? If we require that all relevant targets are > enabled, both for the <superdatastore> and its underlying <datastore>s, > then SelectProfile() can simply instantiate them all. There can't be a a "target" nor a TBinfileImplDS for the superdatastore. TSuperDataStore is a direct and final descendant of TLocalEngineDS. It groups multiple normal datastores from the SyncML point of view and detaches the real work to the fully implemented (i.e. descendants from TLocalEngineDS into TStdLogicDS..TCustomImplDS..TBinFileImplDS..TODBCApiDS..TPluginApiDS). Only the latter can and do have a corresponding target managed by the TBinFileImplDS level. With the <calendar> URI approach, SelectProfile() (or maybe, more generically, dsSetClientSyncParams()) would need to check the URI for the <superdatastore> pattern and if found make sure one superdatastore instance exists (create if needed). > For that to work, TSuperDataStore must be derived from TBinfileImplDS to > avoid segfaults similar to the one seen earlier. Do you agree with > Congwu's approach of changing the base class? Definitely not. TSuperDataStore must remain totally abstracted from any particular implementation class hierarchy (anything beyond TLocalEngineDS), as this would imply to have a backend for it and eventually separate data. >> c) Some tweaking of the for-each-datastore-do-something loops that >> control the flow of a client session (especially syncagent.cpp around >> 1090, where engPrepareClientSyncAlert() is called) > > I see that > engPrepareClientSyncAlert(TSuperDataStore *aAsSubDatastoreOf) > is already prepared to take a TSuperDataStore pointer. But that pointer > is never set anywhere, is it? I only find one call which passes NULL. In the client case, yes. That's why I mentioned that here's the main point of change. That loop must be enhanced such that datastores that are under control of a superdatastore are prepared for alert accordingly (i.e. passing in the matching TSuperDataStore pointer instead of NULL). There might be more to tweak in the other client specific loops that go though the fLocalDataStores list, but at least the loop that creates the client alerts is already superdatastore aware (such that normal datastores under control of a superdatastore will not issue their own alerts). Probably the map sending (which is a client-only thing) might also lack implementation, i.e. in particular reshaping of the localIDs (must be sent with the subdatastore's prefix added). Best Regards, Lukas Zeller ([email protected]) - Synthesis AG, SyncML Solutions & Sustainable Software Concepts [email protected], http://www.synthesis.ch _______________________________________________ os-libsynthesis mailing list [email protected] http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
