Age | Commit message (Collapse) | Author | Files | Lines |
|
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.
|
|
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).
|
|
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.
|
|
- shadowed declarations, clarified them by using unique names
- class with virtual methods need virtual destructor (even empty one)
|
|
libsmltk
|