DBApi - Server URI

[Fatman]

Hi,

We're investigating ability to migrate our software to Synthesis SyncML server (now we use Nexthaus). We're planning to implement database plug-in for our existing database structure.

Current version of SDK covers all our needs except by one - it's really critical for us to have an ability to extract server uri from client in our database plug-in, i.e. making authentication we should use login, password and specified server uri.

And the question is - is it possible to get client's server uri at database plug-in?

[luz]

Current version of SDK covers all our needs except by one - it's really critical for us to have an ability to extract server uri from client in our database plug-in, i.e. making authentication we should use login, password and specified server uri.

And the question is - is it possible to get client's server uri at database plug-in?

Yes. You can implement a small <logininitscript> which gets the server URI using the built-in LOCALURI() function and combines it with the user name from AUTHUSER() to form a single string. Then this string can be set with SETUSERNAME() as the user name string passed to the Login plugin routine.
For example:

<logininitscript>
  string user_and_uri;
  // make string of the form "user@http://my.sync.server/sync"
  user_and_uri = AUTHUSER() + "@" + LOCALURI();
  // set this as user name to be passed to login routine
  SETUSERNAME(user_and_uri);
</logininitscript>

Note that with upcoming 3.1/3.2 version of the SyncML engine (ask for betas if you are interested), the same could be done without combining in the username: plugins have access to all session context script variables (reading and writing) - which makes possible passing any sort of additional information back and forth between engine and plugins.

The mechanism used for this is the same as for settings in the new Client SDK - a tree with named "keys" and "values" (similar to Windows registry). Plugins can query and set sync session variables this way.

BTW: The same mechanism will also get available in 3.1 for the database access routines - instead of passing content data in the text-based "name:value" list format, developers can choose to access fields one using callback routines to access them as "values" from an "item key". The value accessors have useful transformations built-in (charsets, timestamp scales, integers etc.) helping to get and put data directly in the format the plugin needs.

[Fatman]

Thank you very much for this irrefragable answer!