summaryrefslogtreecommitdiff
path: root/src/sysync/multifielditem.h
AgeCommit message (Collapse)AuthorFilesLines
2009-10-03unilib started: engine version 3.3.0.0 to differentiate from normal 3.2.x.x ↵Lukas Zeller1-1/+1
non-unified builds - First walktrough to replace #if(n)def SYSYNC_CLIENT with new unilib macros IS_CLIENT, IS_SERVER which expand to constants in client-only or server-only builds, but query appBase for isServer() when both variants are included.
2009-09-08DBAPI_TUNNEL_SUPPORT: Implemented now. This allows directly accessing data ↵Lukas Zeller1-0/+40
items from the main application (e.g. for test) if DBAPI_TUNNEL_SUPPORT is defined in target_options.h, the engine allows the application to start a pseudo-session that allows accessing any sync-enabled datastore through the engine. The data takes the same way as when read or written during a SyncML session. At the API level, items are presented in the internal "item" format based on the configured <fieldlist>. These items can be accessed on a field level using GetValue/SetValue or in a serialized key:value text format. These are exactly the same mechanisms as used in the DB plugin API. A "tunnel session" always accesses only one datastore. It is started by passing SESSIONSEL_DBAPI_TUNNEL as aSelector argument and a datastore name as aSessionName to OpenSession(). The resulting SessionH can then be used to call the StartDataRead, ReadNextItem(AsKey), ReadItem(asKey), EndDataRead, StartDataWrite, InsertItem(AsKey), UpdateItem(AsKey), DeleteItem. The allowed usage of these routines is the same as described for a DB API plugin in the SDK manual, i.e. StartDataRead() must be first, and before any writing operation StartDataWrite() must be called, etc. For the routines that require a aItemKey passed in, the session key (obtained by OpenSessionKey) can be queried for it's "tunnel/item" subkey. The "tunnel/itemtype" value can be read and written to determine the datatype used for the item (it defaults to the datastore's preferred send type).
2009-06-24MAKE/PARSETEXTWITHPROFILE: added remote rule name parameterremote-rulesPatrick Ohly1-0/+4
If not empty, the remote rule name is used to activate a specific remote rule while using the profile. Otherwise the profile is applied without any active rule, as before. The new parameter is optional, thus macro calls without it still work. This is thus an API extension which is backwards compatible => bumping revision and age. Code linked against old lib still works, code linked against new one requires new one.
2009-06-10warnings eliminationLukas Zeller1-1/+1
- shadowed declarations, clarified them by using unique names - class with virtual methods need virtual destructor (even empty one)
2009-04-17Initial Commit by Synthesis AG for Open Source libsynthesis 3.2.0.25 and ↵opensource-initialSynthesis AG1-0/+371
libsmltk