Hello Patrick, I think by far the simplest method would be NOT to try to bypass MultifieldItem, but derive it with an implementation that puts/gets data (and maybe metadata) into/from well-known string or BLOB fields.
The entire DB API thing was developed long after we more or less settled for TMultiFieldItem as a common denomiantor for all data types. The TField mechanism has proven so useful in various contexts, like the API itself, but also for scripting etc. that while deriving from beyond TMultiFieldItem would still be possible, I see no benefit (and a lot of drawbacks) actually doing so. Sorry for misguiding you with mentioning TSimpleItem in our phone call. But I really would suggest creating a TDirectDataItemType on top of TMultiFieldItemType. That item type could have a hard-coded list of TFields (no need to configure them) representing data and metadata. And it would implement internalFillInData and internalSetItemData which would directly pass data between the SyncML item <data> and predefined text/BLOB fields. This way, there's zero changes towards the DBAPI, all options retained (scripts), and no parallel implementations of similar concepts. If it's of any help for you, I could offer to add such a thing real soon (this weekend?). Best Regards, Lukas Zeller On May 14, 2010, at 9:58 , Patrick Ohly wrote: > Hello! > > I'm working on a modification of the engine which bypasses the > obligatory data conversion via field lists and profiles. The use case > for this are client and server which perfectly agree on some proprietary > item data and thus need no conversion, or plugins which want to handle > the data conversion themselves. > > So far I have hooked up the existing TSimpleItem with the config parsing > (added type and config for it). Now I try to figure out how to read and > write the item data and possibly meta data via the plugin API. > > My initial thought was to expose certain pre-defined field names and use > the *AsKey variants of the API, but that seems to depend on inheriting > from TMultiFieldItem (pluginapids.cpp needs to down-cast to that if > fPluginDSConfigP->fItemAsKey is true). > > Now I'm looking at the traditional API instead (the #ifdef > DBAPI_TEXTITEMS part). > > In that context I have a question about the API as defined in > sync_dbapi.h: > > > * NOTE: By default, the SyncML engine asks for \<aID> only. > * \<aItemData> can be returned, if anyway available or > * \<aItemData> must be returned, if the engine asks for it > * (when calling "ReadNextItem:allfields" at 'ContextSupport' > with \<allfields>). > */ > _ENTRY_ TSyError ReadNextItem ( CContext aContext, ItemID aID, > appCharP *aItemData, > sInt32 *aStatus, bool aFirst ); > > The sentence in the NOTE is a bit long and I don't understand the "if > the engine asks for it" part. How does it call "ReadNextItem:allfields"? > > After reading the documentation of ContextSupport() it becomes a bit > clearer, but not much. Where is the complete list of "support rules" > that the plugin might have to handle? > > If I understand this right, the plugin can choose to support the initial > n rules, but not some specific ones. I assume the ordering of rules is > chosen so that there's never a need to not support, say rule #1 but > support rules #2 and #3? > > -- > 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. > > > > _______________________________________________ > os-libsynthesis mailing list > [email protected] > http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis 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
