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 _______________________________________________ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
