Hi Patrick, Just a intermediate update: I'm still in the process of reviewing your commit 93fa27f124 (implemented superdatastore support in binfile clients).
There's one structural problem with this - it breaks all builds which are not based on binfileimplXXX (not libsynthesis as configured right now, but all of our own servers and command line clients). The thing is that it introduces a dependency on binfileXXX in localengineDS. Even if we could ifdef that out, it means that client-side superdatastores won't be available with non-binfile clients, and thus not compatible with OVI (while I have no idea about absolute relevance of OVI, it is certainly relevant in the MeeGo context). So I'm trying to move your additions for client-side superdatastore up to the abstract level (i.e. localengineDS and syncagent) before I merge with master. I'll work on that right now, so maybe I can commit it today (if not, it might take longer as I'm in vacation next week). In the context of the current default build of libsynthesis, your changes are fine, so I see no reason not to use them in a beta release. Best Regards, Lukas Zeller On Feb 13, 2010, at 15:19 , Patrick Ohly wrote: > On Fr, 2010-02-12 at 17:03 +0000, Lukas Zeller wrote: >> 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 :-) > > That's what I expected ;-) I only asked for hints while looking into the > source further. I later noticed the dependency between initializing the > anchors in the sub-datastores and using them in the superdatastore. > >> 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). > > I got it working without such a change. Of course, "working" and > "working nicely/as intended" are possibly different. Let me know if > you'd like to see it implemented differently. > > > > > -- > 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 ([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
