[SailfishDevel] SyncML topic revived (further down the rabbit hole)

[deloptes]

Chris Adams wrote:

> Hi,
> 
> (Sorry for top posting, OWA doesn't quote properly...)
> 
> That old PR is actually mine, if you're referring to
> https://git.merproject.org/mer-core/buteo-sync-plugins/merge_requests/1
> 
> I think it had some issues (e.g. didn't do UUID matching properly between
> client and server, so it was more of an "import" rather than a true "sync"
> IIRC), which is why it wasn't merged.  Subsequent syncs might cause
> duplication, or changes might not be propagated properly, in one direction
> or the other.  I don't recall precisely.
> 
> Going forward: my personal opinion is that if you can make the required
> changes to the stack to get everything working, we'd definitely like to
> integrate those changes, as it would ensure that we have more parts of our
> stack up-to-date, and less dead-code.
> 
> That said, at this stage I don't believe that it's high priority
> internally, so not sure how much time/effort sailors will be able to spend
> helping with this effort, unfortunately.  Definitely can review and test,
> but may not be able to help with active development day to day.  But am
> always happy to discuss etc (ping chriadam on freenode IRC in .au
> timezone, or perhaps flypig or pvuorela in .fi timezone).
> 
> Best regards,
> Chris.
> 


Hi, so I finished updating and testing, but I feel miserable, because
KF5BluezQt was looking very promissing in the beginning and at the end it
turned out to be of no big advantage to pure Qt5 DBus.
I am not sure if I should not remove KF5BluezQt and write everything only
with Qt5 - despite @blam advocating how good KF5BluezQt is.

The biggest advantage perhaps is that it initializes when the adapter setup
is completed, but - there seems to be always a but and here come the
disadvantages. 
The first disadvantage is that in the background bluetooth is going through
all known devices and registering services that are known to have been
supported to each device.
So at the time I can access the adapter I still do not know if I have to
register the service or not. So if I restart msyncd while BT is on it
crashes like "BUG: scheduling while atomic: kworker/0:1/12981/0x00000002".
There is no issue, when msyncd is restarted if BT is off, because the
application is down - nothing on DBus.

The second big disadvantage of KF5BluezQt is the profile handling. It does
support many profiles, but not the syncml server and client and creating
own profile turned to be very hard, because the profile should handle a
socket/file descriptor, which turns out problematic because of using 
QDBusUnixFileDescriptor and QSharedPointer<QLocalSocket> in combination.
These might be useful for another applications that may be using dbus, but
not for the syncml code that relies solely on filedescriptors outside dbus.

For the moment the solution works fine, but in the area of the above I see
it as a work around over KF5BluezQt limitations.
It might be also me misinterpreting documentation or limited skills.

The fact is I don't know what to do now. The time window I had for working
on this closes. The results are not bad - I can sync two most important -
contacts and calendar+todo like I was doing on the N9, but I wish I would
have the time to try Qt Bluetooth or go it directly via DBus.

The question is to push or not to push :)

Sorry for the long message, but I am not sure what to do next. I'll update
the PoC with what I have on the PC now.

Ideas?

regards