<div dir="ltr"><div><div>>These might be useful for another applications that may be using dbus, but<br>
>not for the syncml code that relies solely on filedescriptors outside dbus.</div><br></div><div>Strictly speaking, I don't see any problem with this - from a syncml client / server</div><div>perspective; was the socket owned by the bluetooth manager also for bluez4 as well?</div><div>If so,  in this regard, there should be no change in responsibility for the syncmlclient/server.<br></div><div><br></div><div>About the KF5BluezQt, I totally agree - hoarding abstractions won't make problems disappear;</div><div>I believe the extent of changes should be the driving force for the final choice (i.e. the least complex</div><div>solution which requires the least changes). Less is more ;) <br><br></div><div>Just my 2 cents.<br></div><div><br></div><div><br></div><div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Aug 4, 2019 at 11:31 PM deloptes <<a href="mailto:deloptes@gmail.com">deloptes@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Chris Adams wrote:<br>
<br>
> Hi,<br>
> <br>
> (Sorry for top posting, OWA doesn't quote properly...)<br>
> <br>
> That old PR is actually mine, if you're referring to<br>
> <a href="https://git.merproject.org/mer-core/buteo-sync-plugins/merge_requests/1" rel="noreferrer" target="_blank">https://git.merproject.org/mer-core/buteo-sync-plugins/merge_requests/1</a><br>
> <br>
> I think it had some issues (e.g. didn't do UUID matching properly between<br>
> client and server, so it was more of an "import" rather than a true "sync"<br>
> IIRC), which is why it wasn't merged.  Subsequent syncs might cause<br>
> duplication, or changes might not be propagated properly, in one direction<br>
> or the other.  I don't recall precisely.<br>
> <br>
> Going forward: my personal opinion is that if you can make the required<br>
> changes to the stack to get everything working, we'd definitely like to<br>
> integrate those changes, as it would ensure that we have more parts of our<br>
> stack up-to-date, and less dead-code.<br>
> <br>
> That said, at this stage I don't believe that it's high priority<br>
> internally, so not sure how much time/effort sailors will be able to spend<br>
> helping with this effort, unfortunately.  Definitely can review and test,<br>
> but may not be able to help with active development day to day.  But am<br>
> always happy to discuss etc (ping chriadam on freenode IRC in .au<br>
> timezone, or perhaps flypig or pvuorela in .fi timezone).<br>
> <br>
> Best regards,<br>
> Chris.<br>
> <br>
<br>
<br>
Hi, so I finished updating and testing, but I feel miserable, because<br>
KF5BluezQt was looking very promissing in the beginning and at the end it<br>
turned out to be of no big advantage to pure Qt5 DBus.<br>
I am not sure if I should not remove KF5BluezQt and write everything only<br>
with Qt5 - despite @blam advocating how good KF5BluezQt is.<br>
<br>
The biggest advantage perhaps is that it initializes when the adapter setup<br>
is completed, but - there seems to be always a but and here come the<br>
disadvantages. <br>
The first disadvantage is that in the background bluetooth is going through<br>
all known devices and registering services that are known to have been<br>
supported to each device.<br>
So at the time I can access the adapter I still do not know if I have to<br>
register the service or not. So if I restart msyncd while BT is on it<br>
crashes like "BUG: scheduling while atomic: kworker/0:1/12981/0x00000002".<br>
There is no issue, when msyncd is restarted if BT is off, because the<br>
application is down - nothing on DBus.<br>
<br>
The second big disadvantage of KF5BluezQt is the profile handling. It does<br>
support many profiles, but not the syncml server and client and creating<br>
own profile turned to be very hard, because the profile should handle a<br>
socket/file descriptor, which turns out problematic because of using <br>
QDBusUnixFileDescriptor and QSharedPointer<QLocalSocket> in combination.<br>
These might be useful for another applications that may be using dbus, but<br>
not for the syncml code that relies solely on filedescriptors outside dbus.<br>
<br>
For the moment the solution works fine, but in the area of the above I see<br>
it as a work around over KF5BluezQt limitations.<br>
It might be also me misinterpreting documentation or limited skills.<br>
<br>
The fact is I don't know what to do now. The time window I had for working<br>
on this closes. The results are not bad - I can sync two most important -<br>
contacts and calendar+todo like I was doing on the N9, but I wish I would<br>
have the time to try Qt Bluetooth or go it directly via DBus.<br>
<br>
The question is to push or not to push :)<br>
<br>
Sorry for the long message, but I am not sure what to do next. I'll update<br>
the PoC with what I have on the PC now.<br>
<br>
Ideas?<br>
<br>
regards<br>
<br>
_______________________________________________<br>
SailfishOS.org Devel mailing list<br>
To unsubscribe, please send a mail to <a href="mailto:devel-unsubscribe@lists.sailfishos.org" target="_blank">devel-unsubscribe@lists.sailfishos.org</a></blockquote></div></div></div>