|
From: Daniel G. <dg...@su...> - 2008-01-08 11:10:31
|
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 |