Patrick wrote: >Congwu mentioned that some workarounds were necessary in SyncEvolution >because the libsyncml test tool didn't set the message type correctly. >What exactly was the workaround - patch? Two workarounds: 1) DEV_TYPE, why are we using desktop? Libsyncml is fairly stick on this and does not accept device types not mentioned in the mandatory list. Shall we change it to something like workstation? 2) The SAN message type as you already know. I think let SyncEvolution to guess the type is a real solution. I may come up with this if no disagree.
Also though SAN message parsing is enabled, obexd test with libsyncml still used the fixed "default" configuration. I think this is more like an interoperability issue and is safe to ignore from transport implementation's eye. >With libsyncml, we can fix the sender. That might not be the case in >other situations. So should we make this workaround an official part of >the D-Bus API and obexd implementation, for example by declaring the >message type as optional so that SyncEvolution knows that it might have >to guess the type? >For the development version leading towards 1.0, please use: > * "dbus-api" in the syncevolution repo > * "unilib" in the libsynthesis repo I have also rebased my obex branch against dbus-api and am improving it to remove any blocking calls. Hoping we will start real test with Forrest's Obexd and SyncEvolution server. -- Best Regards, Congwu _______________________________________________ SyncEvolution mailing list [email protected] http://lists.syncevolution.org/listinfo/syncevolution
