>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.
Strictly speaking, I don't see any problem with this - from a syncml client / server perspective; was the socket owned by the bluetooth manager also for bluez4 as well? If so, in this regard, there should be no change in responsibility for the syncmlclient/server. About the KF5BluezQt, I totally agree - hoarding abstractions won't make problems disappear; I believe the extent of changes should be the driving force for the final choice (i.e. the least complex solution which requires the least changes). Less is more ;) Just my 2 cents. On Sun, Aug 4, 2019 at 11:31 PM deloptes <delop...@gmail.com> wrote: > 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
_______________________________________________ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
