Re: [Opensync-users] Backing up N73 messages (SMS, MMS)

[Daniel G. <dg...@su...>]

On Dienstag 08 Januar 2008, Michael Bell wrote:
> > Arg, yes - that could be as well.. since the latest syncml-obex-client
> > might already send it's own capailities in advance. SyncML Spec says that
> > the device then only should reply supported capabilities by the device...
>
> Why should this happen?
AFAIK, syncml-obex-client has hardcoded datasore support for text/x-vcard, 
text/x-vcalendar and text/plain. If those got set with --slow-sync or --sync 
say got set as preferred type.

Shouldn't be that enough that libsyncml would send the capabilities in 
advnance.. not quite sure about the latest changes in libsyncml. I have to 
take a look on that...

>
> > Not quite sure if syncml-obex-client is already sending the (own) entire
> > capabilities in advance or not.. it's up to your version of libsyncml.
> > Michael Bell that recently lots of development in this area ... we need
> > have to introduce finally same proper discovery function for
> > syncml-obex-client tool (and OpenSync plugin). Not quite sure how hard
> > this is to implement.
>
> The syncml-obex-client is in fact a SyncML server according to the
> protocol. The name is a little bit misleading. I can only test the http
> stuff and here always the SyncML client sends the first DevInf.

Yeah the naming is indeed confusing, it's more related to the transport role. 
The actually correct name would be:

syncml-server-obex-client

Maybe we should rename the process and the plugin. Same for the http transport 
plugins... to sum it up it would be possible to have:

syncml-client-obex-client
syncml-server-obex-client  (aka. syncml-obex-client)

syncml-client-http-client (aka. syncml-http-client)
syncml-server-http-server (aka. syncml-http-server)

Correct?

best regards,
Daniel