Age | Commit message (Collapse) | Author | Files | Lines |
|
The 3529d3cb commit which introduced support for "unprocessed" wildcard
properties added the logic that such properties are always considered
"available" regardless of the actual CtCap of the peer.
This has the undesirable effect that the content of these properties
are removed when receiving an update from a peer which doesn't
support them.
Therefore this commit reverts that part of 3529d3cb: setfieldoptions()
with NULL as first parameter now only enables mandatory properties,
as it did before the introduction of "unprocessed" properties.
"unprocessed" properties need to be listed explicitly in the CtCap
like any other property. This is currently untested.
|
|
|
|
A compare script must know what the compare mode is. When checking for
"items equal", it must return 0 (equal) or -999 (not equal). When doing an
age comparison, it must 1 or -1.
The new COMPAREMODE() method returns a string which identifies the current
mode:
"all", // compare all fields, even irrelevant ones
"n/a", // n/a (scripted)
"conflict", // compare fields relevant for (normal sync) conflict detection
"slowsync", // compare fields relevant for slow sync match
"firstsync", // compare fields relevant for first time slow sync match (possibly relaxed comparison rules)
"age", // no test for equality, only for age (returns SYSYNC_NOT_COMPARABLE if age comparison not possible)
A script only needs to check for "age", and it equal, do the age comparison
instead of checking for equality.
|
|
These functions are used by the XML DevInf parser and thus must
be exported by libsmltk.so, otherwise linking fails.
Perhaps a different API should be used instead. Exporting these
functions seemed like the simpler solution for the moment.
|
|
Now the DevInf is parsed in TSessionConfig::localResolve(). The result
is stored in the TRemoteRuleConfig instance.
The advantage is that syntax errors are found earlier and for all
remote rules, not just the one active during a sync. The downside is
somewhat increased memory and CPU consumption.
The DevInf in XML format is kept in memory although no longer needed
after localResolve(). That might be useful for debugging.
|
|
Many SyncML servers send DevInf without CtCap inside. For those
servers, the engine (often incorrectly) has to assume that they
support all fields.
This patch adds a configuration element "OverrideDevInf" which helps
to address this problem. It may occur in a "RemoteRule". Once that
rule matches a DevInf sent by a peer, processing of CtCap continues
with the CtCap element of the DevInf inside the remote rule. This
allows adding and overriding the CtCap from a peer.
"OverrideDevInf" must contain a complete DevInf, although right now
only the CtCap inside it really matters.
This approach has the advantage that it can reuse the existing and
somewhat documented CtCap format for describing capabilities. The
downside is that not everything can be encoded in that format, for example,
how many components of the ORG field are supported. A possible
solution for that is to extend the format in a way that only the Synthesis
engine understand and/or standardize such extensions.
Right now the "OverrideDevInf" content is only parsed when needed.
Beware that syntax errors will only be found when using the rule!
|
|
Hide the pragmas inside ifdefs to avoid complaints from other
compilers about unknown pragmas.
|
|
The name clash is okay in this case. The two virtual methods
really can be overridden separately. Tell clang that via
pragmas. The pragmas themselves are inside ifdefs to avoid
complaints from other compilers about unknown pragmas.
|
|
This reverts commit 487d78832ca43879902dd0a119fcc2015c50e88c.
Will fix the clang compiler warning differently.
As Lukas explained:
These two versions of apiEndDataWrite() must both exist. It's a historic thing:
- TBinfileImplDS always had no-op apiEndDataWrite(void), that *could* be overridden
by direct descendant (which exist e.g. in non-OS WinMobile and PalmOS datastores)
- TCustomImplDS always had abstract apiEndDataWrite(string &) which has to be
implemented in a descendant (and is, in odbcabidb and pluginapidb).
|
|
gcc 4.6 seems to change header dependencies. cstddef must
be included explicitly. Kudos to Peter Robinson for
reporting this and providing the patch.
|
|
The code added in commit e8b3e088fdc894cade81472412817c01c7cef57f
only acticated sub-rules directly included by the rule specified
as parameter of MAKE/PARSETEXTWITHPROFILE().
With this patch, TMimeDirProfileHandler::activateRemoteRule()
activates sub-rules recursively. As before the settings of
a rule are activated before activating sub-rules, so they
may overwrite their parent's settings again.
Because setRemoteRule/activateRemoteRule() are only used
by scripts, syncing is not affected by this change. I haven't
checked whether recursive inclusion is handled there.
|
|
In a client, PEV_ALERTED was reported to the app with the final sync
mode. On the server, that was missing, partly because the
determination of the final sync mode has to be delayed a bit.
This patch moves the progress event into the one place that is called
in all cases: TLocalEngineDS::changeState() for aNewState ==
dssta_syncmodestable. There it is executed for client and server.
|
|
clang 2.9 detects comparisons which are always true, like "unsigned
value >= 0", and warns about them. In some cases the usage of a signed
type prevents detecting underflows (argidx = c-'1'), in another it
means that error handling was never done (fread() returns 0 on error,
not -1).
Fixed by switching (back?) to signed types and casting to unsigned
after sanity check and before comparison against other, real unsigned
types.
|
|
clang 2.9 pointed out that apiEndDataWrite() existed in versions
with and without parameter. Unified that to the version with
a string retval.
Probably never mattered because all implementations are empty?!
|
|
libsynthesissdk calls libsmltk directly (in san.cpp). libsmltk used to
be provided via libsynthesis, but only if really linked (not always
the case, for example when using the SDK in "open engine dynamically"
mode) and indirect linking stopped working with more recent Linux
bintools which enforce that all libraries are properly declared.
This patch fixes this both in libtool linking (.la files, LIBADD) and
pkg-config definition files (.pc files).
|
|
The VERSION set by AM_INIT_AUTOMAKE() was only used in the *.pc files
and has never been updated since the initial Linux release. Bumped it
to 3.4, so that SyncEvolution can test for a recent enough libsynthesis
during configuration.
Also incremented the .so. New features were added, without breaking
backwards compatibility. This is not quite the same as extending the
ABI, but close.
|
|
With these fixes, clang -Wall -Werror -Wno-unknown-pragmas compiles
cleanly.
Changes:
- short <-> int mismatches in printf formatting
- NULL format string causes a warning (okay in DebugOpenBlock(), but
cannot tell the compiler -> disable checking in that one place
where it happens)
- return NULL pointer instead of implicitly converting false to NULL
- use curly brackets to denote empty body because clang does not
accept a single colon
|
|
|
|
encoded properties not to be decoded any more. This was introduced with 3529d3cb09
- only for unprocessed properties, encodings other than QP must not be decoded.
This condition was missing, so normal B64 encoded PHOTO etc. was no longer
stored as decoded binary in BLOB fields as intended, but stored as-is.
- improved comments regarding "unprocessed"
- some whitespace cosmetics
|
|
Conflicts:
src/sysync/mimedirprofile.h
Some conflict around the added comments.
|
|
modes like BDAY, which is removed again)
In <value>, the "conversion" attribute now can not only
contain the basic conversion mode, but also some
options, which are appended with a + sign:
<value field="BDAY" conversion="DATE+EXTFMT"/>
The defined options so far are:
- EXTFMT: display dates and times in ISO8601 extended format
- MILLISEC: show time with millisecond resolution
|
|
case for this property, even in vCard 3.0).
Notes:
- parsing ISO8601 extended format was implemented for
a while already (for all dates/times)
- in vCard 2.1 both extended and standard format is
allowed. In vCard 3.0 only extended format is in the specs.
|
|
|
|
unknown extensions (like X-xxxx properies)
The properties matched by a wildcard definiton (usually "X-*", see example below)
are stored entirely (including name and parameters) in item fields.
However, the properties are stored not totally unprocessed, but in a normalized form
that removes any dependency from old vCard 2.1/vCalendar 1.0 vs vCard 3.0/iCalendar 2.0
specifics.
This allows reading X-xxx properties e.g. from a vCard 2.1 and reproducing them in a
vCard 3.0 and vice versa.
The normalized form is as follows:
- Folding is removed
- strings are always UTF-8. When parsing a old vXXX-format with a CHARSET parameter indicating
a different charset, the strings are converted to UTF-8 and the CHARSET parameter is
removed from the normalized form.
- Linefeeds within the data (multi-line strings) are represented as plain LF characters within strings
- Quoted-Printable encoding (often needed in old vXXX formats to represent multi-line content) is
decoded and the ENCODING parameter is removed from the normalized form.
- Backslash escaping is NOT removed (except for the special case of \n in new vXXX formats
which is converted to a real LF character).
An example:
- In the config, define a array for the unknown properties
<fieldlist>
...
<field name="XPROPS" array="yes" type="string" compare="never"/>
</fieldlist>
- add a wildcard property definition at the end of the profile (for calendar, insert
a copy into both VTODO and VEVENT subprofiles).
It would also be possible catching all unknown properties using "*", but make
sure the wildcard specs comes after all other properties because the first match
is used when parsing.
Properties with a wildcard name must have a single <value> spec which should
be a string field/array which receives the normalized form of the matched
properties found.
<property name="X-*" suppressempty="yes" show="false">
<value field="XPROPS"/>
<position field="XPROPS" repeat="array" increment="1" minshow="0"/>
</property>
Now a property in a iCalendar 2.0 (without folding here) like:
X-TEST;PARAMETER1=nonquoted;PARAMETER2="quoted and with separators inside:;,":Content with\nMultiple\nText lines\nand national chars: äöü
becomes
X-TEST;PARAMETER1=nonquoted;PARAMETER2="quoted and with separators inside:;,":Content with
Multiple
Text lines
and national chars: äöü
in the internal representation and renders back into iCalendar 2.0 as:
X-TEST;PARAMETER1=nonquoted;PARAMETER2="quoted and with separators inside:;
,":Content with\nMultiple\nText lines\nand national chars: äöü
or as vCalendar 1.0:
X-TEST;PARAMETER1=nonquoted;PARAMETER2="quoted and with separators
inside:;,";CHARSET=UTF-8;ENCODING=QUOTED-PRINTABLE:Content with=0D=0A=
Multiple=0D=0A=
Text lines=0D=0A=
and national chars: =C3=A4=C3=B6=C3=BC
Assuming the property comes from a device that only does ISO-8859-1 and vCalendar 1.0 it might
look like:
X-TEST;PARAMETER1=nonquoted;PARAMETER2="quoted and with separators
inside:;,";CHARSET=ISO-8859-1;ENCODING=QUOTED-PRINTABLE:Content with=0D=0A=
Multiple=0D=0A=
Text lines=0D=0A=
and national chars: =E4=F6=FC
The internal representation will be the same as above (UTF-8 and CHARSET and ENCODING params removed):
X-TEST;PARAMETER1=nonquoted;PARAMETER2="quoted and with separators inside:;,":Content with
Multiple
Text lines
and national chars: äöü
So this allows converting back and forth between old and new vXXX formats for many unknown
extension properties, even if these contain non-trivial data with national chars and linefeeds.
Of course, more complex properties like those containg date/time with TZIDs etc.
will not transfer semantically correct, but still syntactically ok such that a parser should
be able at least to read over them without stumbling.
|
|
conversion options
So far the optional rule parameter was only used to select properties
in the profile via their "rule" parameter. In contrast to a sync session,
it wasn't possible to enable <noemptyproperties>, for example.
This patch makes that possible by extending the
TMimeDirProfileHandler::setRemoteRule() semantic: now each rule and
its sub-rules are also check for relevant conversion settings. Because
there is no session where these settings could be stored, some code had
to be copied from TSyncSession::checkRemoteSpecifics(). For the sake of
completeness, all settings which do not apply are still in the patch
as lines that were commented out.
Because setRemoteRule() is not used outside of these two script macros
(clarified in a comment), this change has no negative effect on
syncing.
|
|
pointer
It is a bit confusing that TMimeDirProfileHandler::getOptionsFromDatastore()
depends on fRelatedDatastoreP to get a session pointer when it also
could use its own getSession(). The reason is that when running as part
of a script, fRelatedDatastoreP is NULL and thus copying the wrong
options for the remote peer from the session is avoided.
This patch clarifies that and replaces the many calls to
fRelatedDatastoreP->getSession() with a local variable. It also checks
that the result really isn't NULL.
|
|
TBinfileImplClient::SelectProfile() checked whether a server URL was
configured. Such a URL is not needed in some cases, for example when
using a pre-configured transport, as in SyncEvolution's local sync
(Synthesis client <-> Synthesis server communicating via pipes).
Setting a dummy URL would have worked around the issue, but is not
the right solution. Removed the check instead.
|
|
code changes)
- luz no longer at Synthesis, but plan44.ch
- Shared copyright for libsynthesis/sysync code pool
- All files copyrighted until 2011
|
|
DBG_ADMIN+DBG_EXOTIC
(DBG_DATA is for payload data, DBG_ADMIN for admin data like mapping etc.)
Also some whitespace cosmetics is included
|
|
Conflicts:
src/sysync/localengineds.cpp
src/sysync/mimedirprofile.cpp
|
|
execute on the new connection, but on the old one.
The problem was that a script statement on the old connection
could still exist at the time SQLEXECUTE() was called out of
a <afterconnectscript>.
Now we close the script statement BEFORE creating the new
connection rather than after.
|
|
SQLINTEGER in 64bit
|
|
This has lead customimpl to think that the already deleted server item
would still exist (but it doesn't, only the map entry did), and
returned a 418 to stdlogic, which then tried a replace, which
failed with 404 (obviously).
Checking mapflag_pendingDeleteStatus now reveals if the actual DB
entry is still there or the map entry only exist because the delete was
not yet confirmed.
|
|
|
|
XCode can't be convinced to not using spaces when indenting,
despite the "Tab key inserts tabs, not spaces" preference unchecked.
|
|
Before, all items that had a localID (=all) were run through adjustLocalIDforSize(),
so even if <alwayssendlocalid> was configured to off, even replace and delete
items received a tempGUID, which then was removed in newSyncOpCommand() again.
This is rather inefficient as it causes map items to be generated and even made
persistent in the DB that are never used at all.
The solution was to move both tempGUID checking/generating and ID prefixing
(needed for superdatastores) into newSyncOpCommand() after the point where
the decision for including a localID or not is made.
|
|
be cleared when first <Sync> is received.
Until now, the tempGUIDs were cleared only once when <Alert> was received.
This is ok to create a clean starting point for loading previous session's
tempGUIDs, which might be needed to resolve "early maps" also related to
the previous session.
However, as soon as the current session starts <Sync>ing, that is,
exchanging new items, these temporary IDs become invalid and
fTempGUIDMap must be cleared once again.
The missing cleanup has led to collisions in the tempGUID name space,
because the tempGUIDs are created based on the fact that the list
is empty at the beginning of <Sync>. As it could have entries
from (possibly much!) earlier sessions, all sort of weird things
could and did happen.
Thanks Patrick for the extensive investigation of this!
|
|
array index -1 now returns status.
- DB_NotFound (404) for array index -1 means unassigned
- DB_NoContent (204) for array index -1 means empty array
- LOCERR_OUTOFRANGE (20042) for array index -1 means array is
assigned and not empty (but does not return a value).
|
|
generate an empty property (and NOT no property at all)
Before, we had the same condition as for non-valuelists, which treats exhausted array
different from empty value when property has a repeat (i.e. has a name extension).
This caused empty CATEGORIES to be omitted even if suppressempty was not configured for it.
|
|
vCalendar 1.0 RRULE (date-only not allowed, must be date+time)
For all-day entries, RR_END can become a date-only value
(for example when read in via iCalendar 2.0). Up to now,
rendering these as vCalendar 1.0 resulted in an invalid
RRULE containing a date-only recurrence end specification.
This patch makes sure the recurrence end specification
is always shown as a datetime (23:59:59 on the last
occurrence)
|
|
(now called "start of release period for product")
|
|
profile is zapped (with separate changelogs)
With combined changelog, it is inevitable to make the other profiles do a slow sync to
keep consistency (so this patch does not change that).
Also, with separate changelogs, we can keep syncs in other profiles resumable without
restrictions, so cancelling resumeAlertCode is not done any more with separate
changelogs (but is still required for combined changelog).
|
|
warnings.
|
|
wrong bytes
|
|
|
|
|
|
engine still missing)
- implementation added
- db adapters: demo/silent/oceanblue and textdb extended
- "plugin_datastoreadmin_xxx" defs added
- Da_LAK/Da_SAK defs added
- dbapi extension
- new functions at connection bridge added
- Java signatures for new functions added
- logger extended
- added check for Plugin_DS_Admin before trying to assign the admin stuff to make
sure plugins w/o admin still work.
|
|
|
|
The size of the buffer into which DevInf was encoded was limited to
~12KB, regardless of which message size was configured for the actual
message.
12KB is too small for larger numbers of databases, like 15, which
caused "SmlException: SyncML Toolkit error=0x2002, smlResultsCmd,
smlerr=8194".
This patch uses a DevInf buffer size which is as large as the
remaining buffer for the actual message, or the old size (just in
case, not expected to be used anymore).
|
|
Conflicts:
src/sysync/itemfield.cpp
Merge conflict because newItemField() was fixed for SyncEvolution.
Same fixed in slightly different code was also in "luz" branch.
|