[SailfishDevel] SyncML topic revived (further down the rabbit hole)
deloptes at gmail.com
Tue Aug 6 00:45:04 UTC 2019
Tone Kastlunger wrote:
> 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?
No, the problem is with Qt5 - There was a totally different mechanism and
the service interface was removed in favor of profile. Anyway - the problem
is even not there, but in the kf5bluezqt implementation of profile I guess.
I was not looking further anymore.
> 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.
Thank you for the moral support. I do not know what is more or less. There
are these 2-3 classes that need to be reworked anyway. I am happy with this
POC for now, but I wish I had the time to do it in qt bluetooth now.
The background is that I asked and Chris suggested to choose one and that
kf5bluezqt was used in other projects. I did not know either qt5 bluetooth
or kf5bluezqt. The latter seemed appealing and this is how I decided to use
it. Then Chris mentioned @blam was more into bluetooth, who was sober
reviewing the changes on buteo-syncfw and was wondering why I would use qt5
dbus instead kf5bluezqt. I am now convinced this was a good choice and I'll
look forward to find the time and do a second PoC with qt5 bluetooth - just
for the exercise. They offer QBluetoothSocket which seems to be more
appropriate than a LocalSocket and perhaps also the low level c-style
socket functions will disappear.
I will not push a MR for now - will do the second PoC and we'll see. At the
end we may end at DBus again :D
More information about the Devel