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