| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
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.
|
|
|
|
|
|
changes related to SAN 1.1
|
|
|
|
to be moved as well to support the Chinese character set (CHINESE_SUPPORT #defineD)
|
|
When a client was requested to suspend, datastores that
had already successfully finished syncing were still
considered "aborted" and thus did not save their
anchors properly.
With this change a late suspend will only affect
datastores that were still in progress at the
time of suspend. Already completed datastores
will save anchors and will NOT resume in the
next sync.
|
|
getItemByID assumed that all items to be read were part
of the syncset which is obviously not the case for
newly inserted items.
So in case the item is not found in the sync set, we
must try to directly load it from the DB.
This bug only affects customimpl on binfile AND
change detection by CRC enabled. No product before
the Android client used this combination so far
so it did not surface until now.
|
|
|
|
When an item that was split among messages was finally reassembled
and processed by the server, the status sent to the client was not
properly stored in the admin data. As a result of that, when the
session got suspended directly after sending that status, the client
would resume, send the last item chunk again, but then not get
the previous status. Instead the server attempted to parse the
incomplete item and failed.
The root cause was that TSyncSession::process() was called
recursively. The inner one for the incomplete command saved the
status in fLastItemStatus. The outer one then later didn't have
a status pointer, fell back to status 0 and overwrote the valid
status.
This patch solves this by suppressing that second updating of
fLastItemStatus and all related fields if the item was handled
by an inner process() call.
|
|
|
|
stringutil is inflated to add several functions from stringutils so
that we can keep stringutil as enough for SDKs
Unnecessary needed utility functions in sysync_utils is disabled in
SDK build by wrapping inside #ifdef SYSYNC_ENGINE
|
|
|
|
|
|
|
|
Making these properties available for a user of TBlob is useful
because then the user can computer some values, call Init() and
later retrieve them without having to store its own copy.
SyncEvolution does that with the blob path. The other properties
are added in this patch for the sake of completeness.
|
|
1. We check the 'version' field in the SAN package to match 1.0/1.1/1.2,
otherwise we consider this as invalid.
2. The PassSan API is changed to add a new parameter 'mode', which defaults
to 0 (try both SAN 1.2 and SAN 1.1 if applicable), however user can also
set 'mode' to 1 to try SAN 1.1 only and to 2 to try SAN 1.2 only.
3. workspaceSize is enlarged from 1024 to 1024*30 since we may accept invalid
resonably large SAN message.
|
|
Use PreparePackage and GetPackageLegacy to generate a 1.0/1.1 version
SAN package.
Linker script it updated to expose the used API.
|
|
Linker script is updated to expose the newly used API.
|
|
The problem was already fixed in client mode, the same problem and fix applied
for server mode.
|
|
This remained undetected because most clients, including
libsynthesis itself before a few months ago, always used
<Replace> and never <Add> (which is ok for a client to
do).
Now an <Add> with an already known remoteID will be
detected and causes implProcessItem() to return
status 418.
This status will be either reported back to the client
in a resumed session, or in a non-resumed session
with updates not explicitly ignored the operation
will be implicitly converted to a <Replace>. In the
server case, 208 status will be returned.
Note that for the client case, duplicate adds are
detected and prevented entirely differently (by
checking against list of pending maps = IDs of
not completely confirmed and mapped adds from the
previous session).
|
|
- added <buffersretryanswer> config flag to signal that transport
buffers server responses and can re-send them when needed.
- SessionStep() in server case may (if <buffersretryanswer> is enabled)
return STEPCMD_RESENDDATA to indicate that the previous response
should be resent to the client. After that, the state machine is
expecting STEPCMD_SENTDATA again. Note that the engine does NOT
provide the data to be resent, so don't call GetSyncMLBuffer after
STEPCMD_RESENDDATA. The caller must buffer the data itself.
|
|
3.4.0.5: implemented client-side superdatastores...)
In both server and client case, status 508 is ok and must
not abort processing subdatastores.
In server case, the presence of a subalertcmdP already means
that the processing is ok, so the check needs only be done
for subalertcmdP==NULL (i.e. client case and server
problem case)
|
|
While a SyncML server session was active, I removed the directory
and the log file that the server was using. The next time the
server tried to log something, it segfaulted in the fclose(fFile)
because of the NULL pointer from fopen().
Don't do anything if the file cannot be opened.
|
|
The API should be unchanged compared to previous releases, but
the implementation has been improved.
|
|
When the client has alerted a superdatastore in a SyncML server
and then is sent DevInf, the server produced a <DataStore>
entry <DevInf> for the superdatastore and each sub-datastore,
all with the same <LocURL> (the one that was alerted).
This is redundant at best, and confusing the client at worst.
This patch detects that a datastore was alerted as a sub-datastore
and skips it when generating <DevInf>.
|
|
|
|
suggestion/draft implementation of Patrick
- Re-implemented along Patrick's changes in his working implementation,
but making it generic and no longer depending on binfile classes,
such that it should work with console clients as well.
- changed the superdatastore trigger syntax from <super:remotepath>
to the already discussed <super>remotepath
- tested ok against synthesis IOT calendar (with iPhone client).
|
|
in log
|
|
The following config variables can now be used to override
default (hardcoded and/or from platform adapter):
customdevicetype, customfirmwareversion, customhardwareversion,
custommodel, custommanufacturer
Note that the same can also be overridden in the config
using <devicetype>,<firmwareversion>, <hardwareversion>,
<model>, <manufacturer> (since early 2009)
|
|
when "customdeviceid" is defined it will be used instead of the
id determined by platform adapters.
Notes:
- "customdeviceid" is considered to be truly unique when defined.
- The value used for the device ID on the SyncML level might
be a MD5 hash of the real device ID and the user name when
required.
- the "device_uri" predefined config variable always returns
the device ID as determined by platform adapters.
|
|
It uses syncml:syncml as the namespace where we only support SYNCML:SYNCML
before;
It sends '+' as an html entity "#43" which the libary did not handles.
|
|
cbVersion is only used inside the #ifdef. When that code is not active,
gcc warns about it being unused and (with -Werror) refuses to compile.
|
|
418 = item already exits: sent by Funambol server when both client and
and server have a new item which is considered identical by the server
(must be really identical, minor difference will lead to a merged item
which is sent back to the client without the 418).
This patch treats 418 as an "okay" status code and lets the session
continue.
Found in SyncEvolution, see Moblin Bugzilla #4599.
|
|
Calling ABORTDATASTORE() normally aborts the whole session.
Passing the new LOCERR_DATASTORE_ABORT avoids that. However,
servers might get confused when a client stops sending information
about one store, so someone using this special status code
should better know what they are doing...
|
|
rules per session
- as before, unless a rule has the <finalrule> flag set, all
remote rules will be checked for a match, and all matching
rule's behaviour flags will be combined.
- UNLIKE before (where the last matching rule was considered
the one and only "active" rule), now all matching rules
are kept in a list and all considered active.
- Using <include rule="..."/> in a remote rule,
a matching rule can activate other rules.
- Using <subrule> (instead of <remoterule>), rules can be
defined that never match by themselves, but can only be
activated using <include name="..."/>
- The REMOTERULENAME() script function still returns the
name of the LAST activated rule (which, unless <include>
is used, is the LAST matching rule, and is therefore
backwards compatible with pre 3.4.0.4 configs.
- A new ISACTIVERULE() script function allows to test
if a certain rule is active (by name). This is meant
to replace REMOTERULENAME()=="xxx" checks.
- Rule-specific property definitions (<property rule="xxx")
and rule-specific datatype usage
(<use datatype="x" ... rulematch="rule"/>) now are activated
by ANY of the active rules .
|
|
|
|
normal libsynthesis builds
|
|
|
|
|
|
- Comment 1.7.0 adapted correctly
- DBG_GET_SET_VALUE added
|
|
The sample configs contain common elements (datatypes, scripts, remote
rules, debug settings) which are maintained as separate files in the
corresponding directories. When modifying those common elements, run
"update-samples.pl" in this directory to update the sample configs.
The complete samples are under version control for several reasons:
1. avoid dependency on Perl unless common elements need to be updated
2. effect of changes on complete config show up in patches
3. the file layout and unshared parts (<client> and <server>) are
determined by the sample configs
The naming of common elements determines the order in which they get
inserted. Files not ending in .xml are ignored. Elements that only
apply to a client or server are stored in the corresponding sub
directories, while the shared elements are in the
"debug/scripting/datatypes/remoterules".
It is a somewhat subjective choice which elements are stored in one
file and which ones are split up. The three elements of a datatype
definition (field list, profile, datatype) where split up because
there might be multiple different profiles using the same field list
and some users of these files might want to replace the default one.
This patch unifies some definitions in client and servers. These
user-visible changes are:
- <folding>auto</folding> and <disable option="match"/> added to client
- unused SYNCLVL field added to client
- bookmark CATEGORIES definition in client updated to the more versatile
one from the server
- minor white space and comment changes
- "note" -> "note10", "vbookmark" -> "vBookmark", "vbookmark" -> "vBookmark10"
renames in server to be consistent with client
As Lukas pointed out, the email scripts and datatypes are server
specific because they depend on server-only methods. A normal client
doesn't need them anyway resp. has to implement email support
differently.
|
