Re: [os-libsynthesis] DB API + simple type
On Fri, 2010-05-14 at 10:46 +0100, Beat Forster wrote: 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 ? No, I'm thinking about the actual item content. 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. Ah, okay. So what exactly is the meaning of ReadNextItem:allfields? What effect does it have when the plugin refuses to acknowledge that rule? -- 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 os-libsynthesis@synthesis.ch http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
Re: [os-libsynthesis] DB API + simple type
Hi Patrick 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. Ah, okay. So what exactly is the meaning of ReadNextItem:allfields? What effect does it have when the plugin refuses to acknowledge that rule? The whole item contents will be re-read with ReadItem later, if refused. When supporting the rule, the engine gets all fields already with ReadNextItem, so they needn't to be re-read later. This enhances significantly performance, if ReadNextItem anyway reads the whole content of the item, so this needn't to be done twice then. 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
Re: [os-libsynthesis] DB API + simple type
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 os-libsynthesis@synthesis.ch http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis Lukas Zeller (l...@synthesis.ch) - Synthesis AG, SyncML Solutions Sustainable Software Concepts i...@synthesis.ch, http://www.synthesis.ch ___ os-libsynthesis mailing list os-libsynthesis@synthesis.ch http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
Re: [os-libsynthesis] DB API + simple type
On Fri, 2010-05-14 at 17:28 +0100, Lukas Zeller wrote: 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. Yeah, I noticed. I have a sync starting based on the TSimpleItem and the string-based API, but now I run into more places where a TMultiFieldItem is expected, like for example in customimplds.cpp: 3118 // - create dummy item 3119 TStatusCommand dummy(getSession()); 3120 TMultiFieldItem *delitemP = 3121static_castTMultiFieldItem *(newItemForRemote(ity_multifield)); 3122 delitemP-setSyncOp(sop_delete); 3123 PDEBUGPRINTFX(DBG_DATA,( 3124Zapping datastore: deleting %ld items from database, 3125(long)fSyncSetList.size() 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. Initializing a TMultiFieldItem(Type) seemed more complex than necessary, but I agree, it probably is easier to set it up right and just use it. If it's of any help for you, I could offer to add such a thing real soon (this weekend?). That would be a big help. I'm fairly confident that I would get it done myself (in particular after having spent some time with the code), but there might be snags that'll delay me that you know how to avoid. My goal was to have something rudimentary next Monday, so if it is not too much bother for you, then I'll punt the problem to you. -- 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 os-libsynthesis@synthesis.ch http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
Re: [os-libsynthesis] DB API + simple type
Hello Patrick, On May 14, 2010, at 19:56 , Patrick Ohly wrote: On Fri, 2010-05-14 at 17:28 +0100, Lukas Zeller wrote: 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. Yeah, I noticed. I have a sync starting based on the TSimpleItem and the string-based API, but now I run into more places where a TMultiFieldItem is expected, like for example in customimplds.cpp: 3118// - create dummy item 3119TStatusCommand dummy(getSession()); 3120TMultiFieldItem *delitemP = 3121 static_castTMultiFieldItem *(newItemForRemote(ity_multifield)); 3122delitemP-setSyncOp(sop_delete); 3123PDEBUGPRINTFX(DBG_DATA,( 3124 Zapping datastore: deleting %ld items from database, 3125 (long)fSyncSetList.size() Yes, customimplds.cpp already makes assumptions. It's not totally generic in the original concept of the engine; that's where it's name comes from, it means something like customisable datastore and was implemented for multifield items only. The original concept did not make any assumptions about what an item would be. 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. Initializing a TMultiFieldItem(Type) seemed more complex than necessary, but I agree, it probably is easier to set it up right and just use it. If it's of any help for you, I could offer to add such a thing real soon (this weekend?). That would be a big help. I'm fairly confident that I would get it done myself (in particular after having spent some time with the code), No doubt! but there might be snags that'll delay me that you know how to avoid. That's why I offer it - I often automatically get an uneasy feeling when I'm about to do something wrong, simply because it rings a faint bell of dead-ends I encountered (and created) myself long time ago :-) That saves some time. My goal was to have something rudimentary next Monday, so if it is not too much bother for you, then I'll punt the problem to you. So let's hack :-) I'll see that I have something for you to test this weekend (on a simpletype branch). Lukas Zeller (l...@synthesis.ch) - Synthesis AG, SyncML Solutions Sustainable Software Concepts i...@synthesis.ch, http://www.synthesis.ch ___ os-libsynthesis mailing list os-libsynthesis@synthesis.ch http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
