| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
This happened to be called several times in SyncEvolution, which reads
two separate XML configs (a preliminary one, then a complete one with
data stores) and thus ended up calling GZones::loggingStarted() twice.
Calling GZones::loggingStarted() is right, so this patch puts an if
check into that function instead of its callers.
|
|
Implementation: a new pair of .cpp/.h: rawdataitemtype plus making the
new type known to syncappbase.
Notes:
- TRawDataItemType is a direct descendant of TMultiFieldItemType;
as such, it works DB-wise exactly like all the other known
datatypes.
- It must <use> a <fieldlist> which must contain one field named
"ITEMDATA". This field could be any type, but only BLOB or string
make sense.
- "Parsing" an item consists of copying the SyncML <Data> content
1:1 (except for <zippedbindata> and <unicodedata> special transforms,
which still apply when enabled) into the ITEMDATA field.
- "Generating" an item consists of copying the content of ITEMDATA field
1:1 (except for <zippedbindata> and <unicodedata> special transforms,
which still apply when enabled) into the SyncML <Data> content.
- "raw" data items can't generate CTCap at this time. This could be
added by having the DB plugin provide a CTCap list or reading
a CTCap definition from the config.
- CTCap received is ignored.
Sample Configuration
--------------------
Notes:
- the dummy field is just there to show that datatype
scripts can be used like in MIMEDIR items
- the essential parameter is the basetype="raw".
- Note that <use> must reference a <fieldlist>, not a <profile>
<datatypes>
<!-- list of internal fields representing raw data -->
<fieldlist name="rawitem">
<field name="dummy" type="string" compare="never"/>
<field name="ITEMDATA" type="string" compare="never"/>
</fieldlist>
<datatype name="vcard21" basetype="raw">
<use fieldlist="rawitem"/>
<typestring>text/x-vcard</typestring>
<versionstring>2.1</versionstring>
<incomingscript><![CDATA[
dummy = "this is a dummy!";
DEBUGSHOWITEM();
]]></incomingscript>
<outgoingscript><![CDATA[
DEBUGSHOWITEM();
]]></outgoingscript>
</datatype>
</datatypes>
and further down the (textdb) datastore:
<datastore name="rawcontacts" type="plugin">
<plugin_module>[SDK_textdb]</plugin_module>
<plugin_datastoreadmin>yes</plugin_datastoreadmin>
<datacharset>UTF-8</datacharset>
<datalineends>unix</datalineends>
<storesyncidentifiers>yes</storesyncidentifiers>
<resumesupport>yes</resumesupport>
<resumeitemsupport>yes</resumeitemsupport>
<!-- Mapping of the fields to the fieldlist "contacts" -->
<fieldmap fieldlist="rawitem">
<automap indexasname="true"/>
</fieldmap>
<!-- datatypes supported by this datastore -->
<typesupport>
<use datatype="vcard21" mode="rw" preferred="yes"/>
</typesupport>
</datastore>
|
|
well
TDBG_LOCATION_xxx macros must be defined in sysync_debug.h
because in some C-only files, debuglogger.h cannot be
included.
Note that actually using SYDEBUG_LOCATION in a monolithic
build would still not work because SYDEBUG_LOCATION
relies on a constructor for a struct which does not
exist in plain C. But this does no harm as SYDEBUG_LOCATION
is not required in any of the classical builds.
|
|
|
|
Note: most of moblin/doxygen changes were already cherry-picked onto luz,
only 58f19738bd (VTIMEZONEtoTZEntry(): flagged failure incorrectly
for VTIMEZONE without summer saving) was missing.
Conflicts:
src/platform_adapters/linux/platform_timezones.cpp
src/sysync/debuglogger.cpp
src/sysync/debuglogger.h
src/sysync/timezones.cpp
src/sysync/timezones.h
|
|
that open BBEdit or TextMate
- timestamps on all log messages is no longer required for source links.
If there is no timestamp to show, the logger will now insert a
small "[src]" prefix instead when source links are enabled.
- <sourcelink> (within <debug>) can be one of "none" (default),
"hint", "txmt", "doxygen".
"hint" only creates a non-active link with a title showing file/line/function
"txtm" creates links that open the file and position the cursor in
MacOS X BBedit or TextMate code editors
"doxygen" behaves as in Patrick's original version
- <sourcebase> can be used to set a base path prefix for generating source
links. It defaults to the value compiled in with SYDEBUG_LOCATION.
|
|
(HTML) log files
For someone unfamiliar with the source code, it is sometimes hard
to locate the code which produced a certain message. This patch
solves this issue like this:
- produce a fully cross-referenced HTML version of the source
with Doxygen
- extend the logging functions and macros so that each message
comes with file name, line number and function name information
- turn the time stamp in the HTML output into a link to the source
code line, with the function name as title
The reason for picking the time stamp was that making other text a
link would interfere with the visual markup of it (color, bold, etc.).
In such an enriched log one can:
- hover over the time stamp to see function name in a bubble help
and the URL (and thus source code location) at the bottom of the
browser window (at least in Firefox)
- click on the time stamp to jump to the source code
Because this feature makes both the library and the logs larger,
it is turned off by default. Configure with --enable-debug-logs
to enable it when using autotools. Macro tricks are used to
produce the same code as before when the feature is off.
Limitations:
- Without time stamp logging, no links are recorded.
- Each change in the Synthesis source code forces a complete
new run of Doxygen. This makes compilation quite a bit slower,
but the only alternative would be to accept that logs and source dump
are inconsistent in the changed parts.
- The links contain the absolute file path (making it a bit harder
to share logs and source code dumps).
- The TClientEngineInterface::debugPuts() API introduced for and used
by SyncEvolution leads to links which contain the wrong absolute
path to the Doxygen HTML files (inside libsynthesis instead of
SyncEvolution).
- The "prefix" parameter in that same API is still ignored.
|
|
Straight from doxygen -g without manual modifications.
|
|
This is a followup patch to integrate Patrick's time zone logging
related changes. No functional changes, only naming, comments,
missing routines in non-Linux platform adapters etc.
|
|
usability of TZ system must be ready before config reading, extra TZ retrieved from system can be added later)
Previously, all parsing of system time zone information was done in the
TSyncAppBase constructor. This had two problems:
1. failure to parse couldn't be reported to app (as mentioned in a
TODO)
2. logging in this fairly complex code was impossible, because
the logger was not initialized yet
This patch adds a finishConfig() callback and uses it to invoke
a second global time zone initialisation function. On Linux, that function is used
to add the libical time zone definitions and logs them at the same time.
Builtin time zones are still added at appBase construction time, before parsing the
config, such that a basic TZ environment is available already during
config parsing.
TZ that only get added in the second init run of course cannot be referenced
in the config file (but that is unlikely to be required at all).
|
|
|
|
Previously, failures in VTIMEZONEtoTZEntry() were
ignored. VTIMEZONEtoInternal() then continued with incomplete
information, typically leading to wrong results.
This patch adds an error message and debug logging. The error message
makes it obvious that something went wrong. The debug logging is
necessary to debug more subtle problems.
|
|
This patch adds debug output at level EXOTIC for parsing the
time zone information in libical. It depends on the previous
patches (NULL check in PLOGDEBUG*, calling time zone parsing
after config reading).
|
|
For someone unfamiliar with the source code, it is sometimes hard
to locate the code which produced a certain message. This patch
solves this issue like this:
- produce a fully cross-referenced HTML version of the source
with Doxygen
- extend the logging functions and macros so that each message
comes with file name, line number and function name information
- turn the time stamp in the HTML output into a link to the source
code line, with the function name as title
The reason for picking the time stamp was that making other text a
link would interfere with the visual markup of it (color, bold, etc.).
In such an enriched log one can:
- hover over the time stamp to see function name in a bubble help
and the URL (and thus source code location) at the bottom of the
browser window (at least in Firefox)
- click on the time stamp to jump to the source code
Because this feature makes both the library and the logs larger,
it is turned off by default. Configure with --enable-debug-logs
to enable it when using autotools. Macro tricks are used to
produce the same code as before when the feature is off.
Limitations:
- Without time stamp logging, no links are recorded.
- Each change in the Synthesis source code forces a complete
new run of Doxygen. This makes compilation quite a bit slower,
but the only alternative would be to accept that logs and source dump
are inconsistent in the changed parts.
- The links contain the absolute file path (making it a bit harder
to share logs and source code dumps).
- The TClientEngineInterface::debugPuts() API introduced for and used
by SyncEvolution leads to links which contain the wrong absolute
path to the Doxygen HTML files (inside libsynthesis instead of
SyncEvolution).
- The "prefix" parameter in that same API is still ignored.
|
|
Straight from doxygen -g without manual modifications.
|
|
summer saving
Parsing a VTIMEZONE with only a STANDARD entry returned a "false"
value for two reasons:
- no DAYLIGHT rules found
- no RRULE in STANDARD component
This patch detects these cases and treats them explicitly like the
code before did implicitly (clear change rules for the DAYLIGHT and
STANDARD parts) without returning an error.
|
|
This patch reverts the "move system time zone parsing after config
reading" part of commit fc000b0f45. As Lukas pointed out, config parsing
already depends on time zones, for example for <definetimezone>.
But this patch keeps the finishConfig() callback and uses it to invoke
a second global time zone function. On Linux, that function is used
to add the libical time zone definitions and logs them at the same time.
Builtin time zones are added at the original time, before parsing the
config.
This is a compromise between having no time zones while parsing the config
and not logging the libical time zones. It works for SyncEvolution, because
it doesn't reference the additional time zones in the config.
|
|
|
|
Previously, failures in VTIMEZONEtoTZEntry() were
ignored. VTIMEZONEtoInternal() then continued with incomplete
information, typically leading to wrong results.
This patch adds an error message and debug logging. The error message
makes it obvious that something went wrong. The debug logging is
necessary to debug more subtle problems.
|
|
This patch adds debug output at level EXOTIC for parsing the
time zone information in libical. It depends on the previous
patches (NULL check in PLOGDEBUG*, calling time zone parsing
after config reading).
|
|
Previously, fAppZones.initialize() and thus parsing of system time
zone information was done in the TSyncAppBase constructor. This had
two problems:
1. failure to parse couldn't be reported to app (as mentioned in a
TODO)
2. logging in this fairly complex code was impossible, because
the logger was not initialized yet
This patch moves the initialize() call after config reading. There are
two such places, one for a real XML config and one for a hard-coded one.
The common code is in the new finishConfig() method, which is only
invoked if there was no previous error and then provides the final
return code for config reading. Like some other code it sets the error
in the config as well as returning a LOCERR_CFGREAD.
|
|
|
|
parsing)
|
|
added LOGDEBUGTEST
|
|
progress events)
- definition of DB_PROGRESS_EVENT in case of disabled progress events was incorrect
- some occurrences of app-level events were not yet using the new APP_PROGRESS_EVENT
macro.
|
|
BYMONTH and BYDAY with a start date that is not an occurrence (happens in some 3rd party VTIMEZONE)
- enhanced RRULE2toInternal by adding an optional aNewStartP paramteter.
If set, the conversion might decide to return an adjusted DTSTART
date.
- Made vtimezone.cpp use the new RRULE2toInternal parameter, such that it will
understand VTIMEZONE having a FREQ=YEARLY, BYMONTH=x, BYDAY=y rule with
a DTSTART that is *not* one of the occurrences of the rule.
- unified formatting style a little bit (deJavaized)
|
|
|
|
|
|
Android - HST/HPT added at tz_table.h (Honolulu)
|
|
|
|
|
|
Note: API is only prepared, but not yet available in the engine at this time
|
|
|
|
|
|
sessions
- new macros for generating progress events
- in engine builds, progress events are strictly
session local now and are directly delivered via
SessionStep.
- in monolithic builds, progress events are still passed
down to the app level and delivered via a app level
callback as in previous versions.
|
|
license
|
|
|
|
Change BASED_ON_BINFFILE_CLIENT to BINFILE_ALWAYS_ACTIVE
so that in combi build server use case, the inherited built in function
table (from customagent) should be chained, thus built in functions there
can be accessed (AUTHOK in my case).
|
|
valgrind reports that fCfgVarExp is uninitialized when being read
by endElement(). Not sure how this can happen, because it should be
set in startElement(). Set it in constructor, just to be sure that
we don't have undeterministic behavior.
|
|
For DevInf 1.1 parsing, DevInf decoding will cause an infinite loop
if there is an empty <PropName> tag (found from Nokia N900,
Nokia 7210c):
eg:
<CTCap>
<CTType>text/plain</CTType>
<PropName/>
</CTCap>
buildDevInfProperty will return OK without further processing if
encountering an empty tag (in this case <PropName>) and the caller
buildDevInfCtCap will re-evaluate the tag without advancing the
parser, the re-evaluation can only end if current tag is an end tag
or an unknown tag, otherwize it will call buildDevInfProperty with
exactly the same environment again.
|
|
Some Nokia phones (N900) sent a nor-wellformed DevInf:
The DevInf version was declared as 1.2, while <CTCAP> was not
inside <Datastore>(which is the DevInf 1.1 behaviour). In addition,
the content inside <CTCAP> was in DevInf 1.2 format.
The original approach detects whether this is a DevInf 1.2 or 1.1
by testing whether <CTCAP> was inside <datastore>, thus will think
this is a DevInf 1.1 when decoding the <CTCAP> which fails.
The patch worked around this, when decoding <CTCAP> (precisely the
<Property> or <PropName> inside <CTCAP>), use 1.2 style if we are
decoding <Property> and 1.1 stype when decoding <PropName>
|
|
The recently introduced SDK_EXCLUDE_FILES temporary file
in src, used by gen-makefile-am.sh, has to be listed in
.gitignore to get a clean "git status" output.
|
|
This is needed for blob db api, it was previously enabled only
libsynthesis engine.
|
|
|
|
by b64::decode/encode
As sysync_b64 was made independent, it can't use sysync_malloc() any
more, but uses normal malloc().
However, all blocks allocated and returned by b64::encode/decode
were still returned with sysync_free(). This only did not hurt
because sysync_free was mapped to free in most (all?) builds.
Anyway, that was ugly so sysync_b64 now includes b64::free()
to clean up the situation.
This patch changes all occurrences of sysync_free() returning
blocks allocated by b64:: routines with b64::free().
|
|
In some cases, the array index was incremented twice,
such that an empty row was inserted into the "table"
represented by the array fields building a grouped
property (like ORG, TITLE and ORG_GROUP).
|
|
|
|
In particular, LOCERR_USERSUSPEND can be returned to
signal that the plugin has detected a external
condition that should suspend the session. All other
errors abort the session.
|
|
|
