[Opensync-users] Sony Ericsson 910i / unkown content type

[Thorsten K. <kr...@in...>]

Hi,

today I play around with libsyncml / syncmlplugin.

1. The SE 910i mobile doesn't use the <meta> <type> tag to specify the
   following CDATA block.
   <Replace>
	<CmdID>5</CmdID>
	<Meta></Meta>
	<Item>
		<Source><LocURI>486</LocURI></Source>
		<Data><![CDATA[BEGIN:VCARD
VERSION:2.1
REV:20051231T105039Z
UID:088ca28734e027f0-00e0e6e8c7a3598f-486
N:ADAC-Pannennotruf;;;;
TEL;VOICE;CELL:+49177222222
END:VCARD
]]></Data>
	</Item>
   </Replace>

   It sends a contact in valid vcard format but the libsyncml-plugin
   _recv_change function is called with an contenttype
   SML_CONTENT_TYPE_UNKNOWN. Due to this, in opensync_context an assertion 
   is triggered:

   osync_context_report_change: The reported change did not have a format set.

   I tracked this back to _smlChangeParse in sml_xml_parse.c, which initializes

   char *contenttype = NULL;

   only modifies this in _smlCommandMetaParse (no type tag there), and finally
   uses

   if (contenttype) {
      item->contenttype = smlContentTypeFromString(contenttype, error);
      if (!item->contenttype)
         goto error_free_cmd;
   }

   to setup contenttype (no effect either, since contenttype is still NULL).

   The SyncML1.1 specification mentions that omitting the <TYPE></TYPE> tag
   means that the default, text/plain, is to be used.
	
2. So now one possibility is that the plugin should somehow deal with those
   unknown content types; either by handling them in the same way as
   text/plain, which is trivial to add. Or by returning an error. I tried to
   get working error handling first by calling osync_context_report_error
   (in the same way that batch committing does); however this resulted in a
   destroyed context after the first error reported, which caused a segfault.

   Returning FALSE from _recv_change (for instance by using goto error;)
   proved to be bad, too, since the caller (smlDsSessionDispatch) doesn't
   remove the items from the dsession->recvChanges list, so the same change
   was performed (and failed) again and again and again.

   So finally the only working method was printing out the error myself and
   returning TRUE (without using goto error).

Thorsten