Hello Patrick
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.
You're talking about LoadAdminData/SaveAdminData ?
Just to avoid implementing things in parallel:
We're preparing right now the asKey variant for
these two routines. Does this solve your problem ?
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.
For bringing meta data from plugin to the engine,
usually the Module_Capabilities can be used, for
bringing information from engine to plugin, there
is Module_PluginParams.
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"?
As string to ContextSupport.
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?
There is currently only this rule supported by
the engine. Originally we thought there would be
much more of them, but this wasn't the case until
today.
There are some test rules used by some of the
test utilities, but not called by the engine.
The filter rules are using the same concept. I
think there are about 3 of them for the date
range checking.
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?
The engine is allowed to call ContextRules
multiple times, so it can reorder the rules and
ask again. Or it can ask rule by rule. The plugin
just returns up to which rule they are supported.
So the engine knows that at least these rules are
supported and the next one is not. Returning 1 or
larger is only allowed if the rule is 100 %
supported. If partly supported, it must return a
not ok (not counting) to the engine.
Best Regards,
Beat
--
-----------------------------------------------
Beat FORSTER
Dipl. El. Ing. ETH
Dipl. NDS ETHZ in Betriebswissenschaften
Managing Partner
beat.fors...@synthesis.ch
Synthesis AG SyncML Server & Client Solutions
Badenerstrasse 18, CH-8004 Zürich, Switzerland
Tel (direct): +41 44 440 66 02
Fax: +41 44 440 66 04
email: i...@synthesis.ch
web: http://www.synthesis.ch
-----------------------------------------------_______________________________________________
os-libsynthesis mailing list
os-libsynthesis@synthesis.ch
http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
