Cross-platform interoperability

[darkhz]

The current objective is to make the app cross-platform (Linux, macOS, Windows mainly).

The requirements are:

(a) Basic device interaction (connect/pair/authentication)
(b) OBEX support (for file transfer)
(c) Control remote playback / change audio profiles
(d) Networking (PANU/DUN)

Since the APIs differ across platforms, and there is no mature library (that I know of) that can handle these requirements, I would like some suggestions from the users/community on how to proceed with this.

For example: tinygo/bluetooth has limited cross-platform support, and its APIs aren't mature. Also, OBEX, remote playback and networking features are not present in the library, and it would be tedious to implement from scratch.

Some ideas:

tinygo/bluetooth

Maybe wait until the tinygo/bluetooth library becomes mature, and then use its APIs.

Qt

The Qt Bluetooth library has broader support for various platforms.

Using the Qt bindings for Golang (this isn't active apparently, a newer fork of this will be used), the Qt Bluetooth APIs could be leveraged.

The caveat is the building process (cross-compilation). Binary sizes may be bigger, but there are methods to reduce the size.

Any more ideas/opinions from the community will be much appreciated.

[ulissesjdeo]

Hi, it will be awesome to have a great and lightweight tools like this one in each platform (despite I personally think it's not necessary, but that's not the point). I got some search and see that the repos that you've pointed are the best for doing this. My point is that at this moment we should wait, in a few months Plasma 6.0 will be released, and a lot of users will be using it and because of that we should wait for lots of issues and improvements about Qt6, by another side Golang is continuous getting better, so both of them are constantly changing, and the fork you've mentioned didn't get commits by a year, so my idea is to wait if any go or qt6 news are going to be implemented in those bindings, possibly what I'm saying doesn't make any sense and that fork will be working extremely fine for years and then it will be updated. Just a fear about investing time in using a possibly dropped project. Maybe getting in contact with repo maintainers?

[darkhz]

@ulissesjdeo I agree, I was planning to wait as well. I did a few experiments with bluekitchen and the Qt6 bluetooth library, but yes, it will take effort and time to build a bluetooth daemon-like service for all platforms.

[darkhz]

[EDIT]
Update on this:

The plan is to write cross-platform lightweight shim like applications natively for each platform, with which the client can interface with via IPC and operate Bluetooth.

For Windows, a shim will be written in C# and for MacOS a shim will be written in Swift.
For FreeBSD, interfacing will be done with blued, NetBSD may be supported later and OpenBSD will not be supported.

A cross-platform daemon will then be built to use the platform specific shims.

The implementation details are still being worked out, so stay tuned.
See: https://github.com/bluetuith-org

If anyone has any suggestions post it here.

[darkhz]

Edited the above comment to reflect new plans.

[NitroNils]

I'd love to hear why OpenBSD will not be supported. I am aware that they don't support Bluetooth, but I'm not knowledgeable enough to know why that can't be implemented in userspace - or how much work that works entail.

[darkhz]

@NitroNils That would be a lot of work, especially with OpenBSD not having a bluetooth stack. Writing a bluetooth stack/implementation (for userspace or kernelspace) from scratch would be very tedious, not to mention support for various protocols and profiles.