Hello Patrick, On Apr 25, 2012, at 15:11 , Patrick Ohly wrote:
> I am trying to solve one issue in SyncEvolution: when trying to find > pairs, it needs to know on a per-datastore basis whether both remote and > local storage have truly unique UID/RECURRENCE-ID that can be relied > upon (iCalendar 2.0 semantic). > > So far, I am using a compare script for that, but it has to make > assumptions about the peer. To overcome that I added code that allows > clients to add SyncCap entries to the CTCap (similar to the "can restart > flag"). This information is stored at the receiving end in the > TSyncDataStore base class by the TRemoteDataStore while parsing the > SyncCap (again, very similar to "fCanRestart"). The problem is that CTCap is not necessarily tied to a datastore. It is since SyncML 1.2, but wasn't before. That's also the reason why getRelatedDatastore() can be NULL. It is also NULL when using a type from a script with the MAKETEXTWITHPROFILE et. al. functions. > But now my problem is: how can the compare script access that > information? > > It runs inside the "datatype context". Does that mean that all > datastores sharing the same type also share the same context and that > the <initscript> for the type is only invoked once? <insert English word for "Jein">. The datatype context indeed exists only once per type, so the script variables exist only once. However, the init script might be called more than once if multiple datastores are using the same type. The TScriptContext object will be the same, but script functions that use fDsP (see below) can return different information. So using these in the initscript usually makes no sense. > The script functions in multifielditemtype.cpp (like SYNCOP()) looked > promising. It's possible to get a pointer to some kind of datastore: > > TSyncDataStore *related = static_cast<TMultiFieldItemType > *>(aFuncContextP->getCallerContext())->getRelatedDatastore(); For getting the local datastore related to a particular script invocation, there is TLocalEngineDS *related = static_cast<TMultiFieldItemType *>(aFuncContextP->getCallerContext())->fDsP; fDsP is one of several variables I'd call "current type usage context", fCurrentSyncOp which feeds the SYNCOP() script function is another one of them (See multifielitemtype.h Line 202 ff). > But in practice that pointer is always NULL. I wasn't sure anyway > whether I would get the pointer to the local or remote datastore. from fDsP you'd get the pointer to the local datastore (TLocalEngineDS *). So to reach the remote datastore from a given TMultiFieldItem (which you certainly have at comparescript), I'd rather use yourMultiFieldItem->getRemoteItemType->getRelatedDatastore() to get to the datastore that has defined that item's remote type. As said, in SyncML 1.1/1.0 cases you'd get NULL back because the devInf does not associate types with datastores at all. But I'd assume your extension does not have to work below 1.2, so that'll be no problem. Best Regards, Lukas _______________________________________________ os-libsynthesis mailing list os-libsynthesis@synthesis.ch http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
