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

[Armin B. <arm...@de...>]

Thorsten Kramer wrote:
> 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.

where exactly did you read this?

i found this on page 37 of syncml_sync_protocol_v11:

(dealing with add, replace and delete)
The type element of the metainf must be included to indicate the type of
the data item (mime type).

> 	
> 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).

we could catch this error in libsyncml and handle it gracefully there.
We know the target database of the sync command and from this database
we can derive the mimetype. So we could overwrite the mimetype there
(but i would make this behaviour optional since it would violate the
standard, at least as far as i understand it).

the other option would be to leave SML_CONTENT_TYPE_UNKNOWN, but set the
format to "plain" and objecttype to "data" in the syncml-plugin.
opensync would then invoke the format detectors which would detect the
correct format of the change.

Armin

> 
> Thorsten