Hi Patrick, I can just say, if you come to the point where a superdatastore seems to need any admin data (profiles, maps, anchors, whatever) you're off track :-)
So, regarding engPrepareClientSyncAlert(): The problem is that this, as a client-only routine, has never been made superdatastore aware, i.e. it's not a virtual (SUPERDS_VIRTUAL) and TSuperDataStore does not have a derived implementation for it (yet). We need an implementation of engPrepareClientSyncAlert() in TSuperDataStore which avoids calling its own inherited (TLocalEngineDS), but instead loops trough its subdatastores and calls engPrepareClientSyncAlert() on those. Have a look at the server case counterpart TSuperDatastore::engProcessSyncAlert() to get the idea. engGenerateClientSyncAlert() and engInitForClientSync() are hot candidates for requiring a similar derived implementation in TSuperDatastore as well... > How should anchor handling work for a superdatastore? TSuperDatastore::engInitSyncAnchors(), which is a server & client routine, already takes care of that (calculates a common anchor value from all subdatastore's anchors, and a common fFirstTimeSync as well). For processing superdatastore's data items, the code is already in place that dispatches incoming Sync Ops to the correct subdatastore - by ID prefix for Replace/Delete and by subdatastore filter for adds (see TSuperDatastore::engProcessRemoteItem()). Same for generating Sync Ops for the remote, this is handled by TSuperDatastore::generateSyncCommands() which iterates through all its subdatastores to get the items to send and prefixes their localID according to the subdatastore they originate from. Finally, I apparently implemented engGenerateMapItems() already, despite the fact this is a client-only routine (That's usually my way of working - if I stumble upon something obviously missing, I add a dummy with a warning output or if it's a no-brainer to code, I just write it, even if there are additional things missing for the feature to work. What I forgot is to mark that code, and everything else related to client-side superdatastores certainly is: UNTESTED). Please let me know if this kind of guidance to the missing links is ok - or if you think it'll be something you'd rather want me to do myself. If the latter, it'll take some time because next week is quite busy and the week after that is snow vacation :-) Best Regards, Lukas Zeller On Feb 12, 2010, at 14:40 , Patrick Ohly wrote: > On Do, 2010-02-11 at 19:50 +0000, Patrick Ohly wrote: > [no target for superdatastore] >> The only solution I see is to make the subdatastore URI's more complex: >> instead of <foo>, let's use <foo:uri> where "foo" is the name of the >> superdatastore and "uri" its remote URI. > > I'm going with that and have syncs running, albeit with some problems. > > One problem is that the client always forces a slow sync for the > superdatastore. That's because of the following line in > TLocalEngineDS::engPrepareClientSyncAlert(): > > // check if we are forced to slowsync (otherwise, fSlowSync is pre-set from > dsSetClientSyncParams() > fSlowSync = fSlowSync || fLastLocalAnchor.empty() || fFirstTimeSync; > > fSlowSync is false, the anchor empty, fFirstTimeSync false. > > How should anchor handling work for a superdatastore? > > -- > 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. > > Lukas Zeller (l...@synthesis.ch) - Synthesis AG, SyncML Solutions & Sustainable Software Concepts i...@synthesis.ch, http://www.synthesis.ch _______________________________________________ os-libsynthesis mailing list os-libsynthesis@synthesis.ch http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
