On 05/29/2012 10:26 AM, Andris Pavenis wrote:
On 05/25/2012 03:53 PM, Lukas Zeller wrote:
As I did not get SyncML TK output I attached yesterdays captured data
which contains 2 sessions:
- the first got response with auth challenge but is otherwise OK
- the second fails as I wrote yesterday. WBXML and XML messages
included together with HTML log
The second session fails because the SyncML document is wrong. The
status for Alert has a<Next> element at the<Data> level of the item
instead of inside an<Anchor> element. This is invalid by the SyncML
DTD.
Is it? Specification (SyncML Representation Protocol, Approved Version
1.2.1 – 13 Aug 2007) says that markups inside Data element are
required to have namespace specification. From that point of view
element Next from namespace syncml:metinf does not seem to be any
worse rather than Anchor. Both are members of syncml:metinf namespace.
I know that examples in MetInf PDF documentation only use Next and
Last inside Anchor.
Also libwbxml2 successfully decodes the message which Syncml TK fails
to decode and indicates that element Next belongs to namespace
syncml:metinf
Accepting Next without surrounding Anchor seems to be sufficient to get
built-in SyncML support on Xperia-S working with libsynthesis based
SyncML server. I have only tested calendar events and browser bookmarks
synchronization (only some short tests done)
I did not implement handling of separate Last element, but it could be
easily also added in the same way.
Andris
>From 4926530f6edad2d0f6ab79c8d7b7385c33cbb426 Mon Sep 17 00:00:00 2001
From: Andris Pavenis <andris.pave...@ipnetworks.fi>
Date: Tue, 29 May 2012 12:21:58 +0300
Subject: [PATCH] Workaround problem with Sony Xperia 2012 (S and perhaps also
P and U) phones
Data element in Alert command contains Next (syncml:metinf)
directly instead of inside Anchor element. Handle this case.
One could easily add also handle element Last in the same way,
but it is not implemented yet.
---
src/syncml_tk/src/sml/xlt/all/xltmetinf.c | 36 +++++++++++++++++++++++++++++
1 files changed, 36 insertions(+), 0 deletions(-)
diff --git a/src/syncml_tk/src/sml/xlt/all/xltmetinf.c b/src/syncml_tk/src/sml/xlt/all/xltmetinf.c
index e171a45..8d88c44 100755
--- a/src/syncml_tk/src/sml/xlt/all/xltmetinf.c
+++ b/src/syncml_tk/src/sml/xlt/all/xltmetinf.c
@@ -119,6 +119,37 @@ Ret_t buildMetInfAnchorCmd(XltDecoderPtr_t pDecoder, VoidPtr_t *ppElem) {
return SML_ERR_OK;
}
+Ret_t buildMetinfNextCmd(XltDecoderPtr_t pDecoder, VoidPtr_t *ppElem) {
+ XltDecScannerPtr_t pScanner;
+ SmlMetInfAnchorPtr_t pAnchor;
+ Ret_t rc;
+
+ pScanner = pDecoder->scanner;
+
+ if (*ppElem == NULL) {
+ if ((pAnchor = (SmlMetInfAnchorPtr_t)smlLibMalloc(sizeof(SmlMetInfAnchor_t))) == NULL)
+ return SML_ERR_NOT_ENOUGH_SPACE;
+ smlLibMemset(pAnchor, 0, sizeof(SmlMetInfAnchor_t));
+ } else {
+ pAnchor = (SmlMetInfAnchorPtr_t)*ppElem;
+ if (pAnchor->next != NULL)
+ return SML_ERR_XLT_INVAL_SYNCML_DOC;
+ }
+
+ rc = buildPCData(pDecoder, (VoidPtr_t)&pAnchor->next);
+
+ if (rc != SML_ERR_OK && ppElem == NULL) {
+ smlFreeMetinfAnchor(pAnchor);
+ return rc;
+ }
+
+ if (ppElem == NULL) {
+ *ppElem = pAnchor;
+ }
+
+ return SML_ERR_OK;
+}
+
Ret_t buildMetInfMemCmd(XltDecoderPtr_t pDecoder, VoidPtr_t *ppElem) {
XltDecScannerPtr_t pScanner;
SmlMetInfMemPtr_t pMem;
@@ -256,6 +287,11 @@ Ret_t buildMetInfMetInfCmd(XltDecoderPtr_t pDecoder, VoidPtr_t *ppElem) {
rc = buildEmptyTag(pDecoder); // allow for <tag></tag> instead of <tag/>
break;
+ /* Next without Anchor, Andris Pavenis 2012-05-29 */
+ case TN_METINF_NEXT:
+ rc = buildMetinfNextCmd(pDecoder, (VoidPtr_t)&pMeta->anchor);
+ break;
+
default:
rc = SML_DECODEERROR(SML_ERR_XLT_INVAL_SYNCML_DOC, pScanner, "buildMetInfMetInfCmd_2");
}
--
1.7.7.6
_______________________________________________
os-libsynthesis mailing list
os-libsynthesis@synthesis.ch
http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
