Using DLT (http://projects.genivi.org/diagnostic-log-trace/home) would make a lot of sense. For example, more detailed debug logging and retrieval of the results could be done via DLT. Details TBD.
Here's how SyncEvolution and libsynthesis support DLT now, code about to be merged into master branches:
Diagnostic Log and Trace
Diagnostic Log and Trace (DLT) is a logging mechanism defined and
implemented by GENIVI: http://projects.genivi.org/diagnostic-log-trace/
SyncEvolution optionally supports DLT as follows:
* syncevo-dbus-server, syncevo-dbus-helper and syncevo-local-sync can
log to DLT. Operations with "syncevolution --daemon=no" never use
* Each of the three processes uses a different application ID. By
default, these IDs are "SYNS", "SYNH", "SYNL". These default can be
changed via configure options. All processes use just one context,
with the fixed ID "SYNC".
* syncevo-dbus-helper and syncevo-local-sync only run occasionally.
This makes is hard to adjust their log levels, for example via the
dlt-viewer, because the processes and their contexts are only shown
(known?) while the processes run. To work around this, the initial
log level of these two helpers are inherited from the
log level of the "SYNC" context in syncevo-dbus-helper.
* That log level defaults to "WARN", which ensures that normal runs
produce no output.
* To enable DLT support during compilation, use
"--enable-dlt" and "--with-dlt-syncevolution=SYNS,SYNH,SYNL" where SYNS/H/L
are the actual application IDs.
* To enable DLT support at runtime, run syncevo-dbus-server with
"--dlt". Logging to syslog should be disabled with "--no-syslog".
* The hierarchical log from libsynthesis gets flattened into a flat
stream of messages and no syncevolution-log.html files are written.
GENIVI Diagnostic Log and Trace (DLT) support
DLT is a logging mechanism defined by GENIVI. It supports the context
of log message contexts (arbitrary groups, defined by the app or
library) and levels (off, fatal, error, warning, information, debug,
verbose). The log level can be set per context, using mechanisms
provided by DLT (for example, interactively via DLT client connected
to a system running the DLT daemon and apps using that daemon).
If DLT support is enabled during compilation of libsynthesis (use
--enable-dlt on Linux) and in the configuration (use "dlt" as
"logformat" and ignore all other logging options), then libsynthesis
uses DLT for logging instead of writing its own files.
libsynthesis has no concept of a strictly ordered log level. Instead
major categories are combined with minor ones, which allows enabling
"more verbose" logging for some aspects of a major category while
leaving "less verbose" ones disabled. When using DLT, a hard-coded
mapping between minor categories and log level is used, so some
flexibility is lost.
The mapping is as follows:
Context ID = Synthesis debug topic: description (from SySync_config_reference.pdf)
PROT = "proto": SyncML protocol related information.
SESS = "session": Session management related information.
ADMN = "admin": Everything that has to do with administrative data (anchors,
targets, map table).
DATA = "data": Everything that has to do with handling user data (data objects).
Actual user data will however be shown only if loglevel >= debug.
REMI = "remoteinfo": This shows information delivered in the remote party's
device information, such as manufacturer name, datatypes supported, fields supported
PARS = "parse": This shows information related to parsing and processing incoming
data from the remote party. Actual user data will however be shown only if loglevel >=
GEN = "generate": This shows information related to generating outgoing data for the remote
party. Actual user data will however be shown only if loglevel >= debug.
TRNS = "transp": Shows transport (http and TCP communication) related information.
SMLT = "syncml_rtk": Messages generated by the SyncML Toolkit code.
SYSY = "rest": Any other debug log message that does not fit in any of the above
The default log level of each context can be set via env variables
called LIBSYNTHESIS_<context ID>, with values from 0 (off) to 6
The log level of a message is derived from the other Synthesis debug topics:
"error" => ERROR: error messages.
"hot"=> INFO: most important information (of all topics). This should never
be switched of (except when switching off debug logging completely).
"userdata" => DEBUG: Anything that is user data. To create anonymized
logs that do not show user's data, use a log level less than debug
(and, depending on the database interface, "dbapi" as well, as it
might show SQL commands revealing user data as well).
"dbapi" => VERBOSE: Information related to accessing the database. For
ODBC, this enables showing SQL statements issued to the database, for
plugin datastores, this includes all communication with the plugins
and also messages generated by the plugin itself (see "plugin" below).
"plugin" => DEBUG: Messages generated by database adapter plugins.
"scripts" => VERBOSE: This is useful to debug scripts, and shows each
line of executed scripts (but only for enabled debug topics!). Switching
this on can generate huge log files, so it should normally be switched
off in productive environments.
"expressions" => VERBOSE: Together with "scripts" this causes detailed
step-by-step logging of script expression evaluation.
"filter" => DEBUG. Information about data item filtering.
"match" => VERBOSE: Information about matching data in slow sync. Note
that together with "exotic" this can produce extremely large logs as
matching is an O(N^2) operation, so use with care.
"conflict" => DEBUG: Information about conflict resolution and data merging.
"details" => increases log level by one. Enabling this option adds
generally some more detail to the debug output.
"exotic" => VERBOSE: Enabling this adds the highest level of exotic detail possible.
This is usually only required to track down device interoperability issues or
bugs in the server/config.