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
