Read on Twitter
[Thread]
Need to do some planning today, might as well do it on twitter.
With the release of Buttplug Unity, it's time to revisit the short-to-medium term roadmap for Buttplug and Intiface.
tl;dr - Definitely hitting that 80/20 point, and the last 20% is going be a slog.
Need to do some planning today, might as well do it on twitter.
With the release of Buttplug Unity, it's time to revisit the short-to-medium term roadmap for Buttplug and Intiface.
tl;dr - Definitely hitting that 80/20 point, and the last 20% is going be a slog.
The goal for Buttplug in 2020 is to centralize on the Rust codebase, with C#/JS/Python/etc handled via FFI on top of C ABI bindings to that.
~6 months in and we're well on track for that. The Rust codebase is major feature complete. Still needs lots of detail work though.
~6 months in and we're well on track for that. The Rust codebase is major feature complete. Still needs lots of detail work though.
My ideal for Buttplug (just the hardware library, not Intiface) is to stop working on it unless we either need new device protocols or new Buttplug messages. 3+ years of rewriting the same thing is getting tedious, and not really advancing the field much at this point.
We're lucky in that "advancing the field" of teledildonics is a ridiculously low bar that we clear even by existing, but there's a difference in clearing the bar and being happy with what you're doing.
Anyways, for Rust, we still need to:
- Firm up errors (moving to thiserror)
- Fix logging (moved to tracing, which is amazing, now just detail work)
- Fill out protocols missing from C#
- Finish device comm impls (serial, HID, Lovense dongle)
- Stablize Bluetooth
- Firm up errors (moving to thiserror)
- Fix logging (moved to tracing, which is amazing, now just detail work)
- Fill out protocols missing from C#
- Finish device comm impls (serial, HID, Lovense dongle)
- Stablize Bluetooth
Finishing the top 2 of those will result in buttplug-rs 0.5.0. Protocols/comm impls can come as demanded.
Bluetooth, though. That one is gonna be non-trivial.
Bluetooth, though. That one is gonna be non-trivial.
Buttplug's bluetooth access works via btleplug, a rust library I also maintain.
btleplug is a fork of an abandoned bluez based library called "rumble". rumble had a pull request for Windows support, and I added mac support. So it works everywhere.
But it doesn't work well.
btleplug is a fork of an abandoned bluez based library called "rumble". rumble had a pull request for Windows support, and I added mac support. So it works everywhere.
But it doesn't work well.
It doesn't feel very rusty, isn't async (not a fault here, the last rumble commit was 5 months before async stablized), and was designed with only bluez in mind. As usual with linux APIs, it doesn't look fucking remotely like what Mac/Win do, so those have to be shoehorned in.
So, this basically needs a ground-up rethink.
However, stablizing btleplug is also extremely important for finalizing buttplug-rs, since most of the hardware we support is bluetooth le.
This means refactoring to a happy medium, not a final gold standard.
However, stablizing btleplug is also extremely important for finalizing buttplug-rs, since most of the hardware we support is bluetooth le.
This means refactoring to a happy medium, not a final gold standard.
btleplug 0.5.0 will have QoL improvements like moving from closure callbacks for events (fine for gc'd langs, not fun in rust) to message streams, and will make sure shit basically works across all platforms. For instance, neither Mac/Win knows when a device disconnects now. >.>
Alongside that, I'd like to build a doc similar to STPIHKAL ( https://stpihkal.docs.buttplug.io ) for bluetooth LE platform APIs, so we can say "here's what other platforms do, here's our best effort distillation of that into a single impl".
Can't wait to see how Android fucks this up.
Can't wait to see how Android fucks this up.
In the end, I'd love to see btleplug as a non-runtimed, cross platformed, FFI'd BLE library that people can use from any language. BLE libraries are few and far between, and some of the best I've seen are in C#, which means pulling xamarin or .Net along for the ride.
Anyways, as you can see, there's just a lot of maintenance work to happen on both Buttplug and btleplug.
The big question becomes "how to stay sane while making sure that gets done while not really getting paid to do any of this?"
The big question becomes "how to stay sane while making sure that gets done while not really getting paid to do any of this?"
The answer is in finding fun small side projects with big impacts. Unity was one of them, I'm really looking forward to seeing what happens with that.
The FFI layers will probably be the next set of projects that happen in that manner.
The FFI layers will probably be the next set of projects that happen in that manner.
Exposing the Buttplug Rust API via C ABI shouldn't really be affected by all of the maintenance work happening under the covers. The only thing that will really be exposed is the Buttplug Client API, and it doesn't really change much.
The hard questions there are mostly figuring out how to take an async Rust API and translate it to non-async languages like, say, C. I've got some ideas here, but there's not much the way of work to copy from, because async rust is new.
There are some good articles on crossing FFI boundaries while keeping types set though, like @TedMielczarek's work at Fullstory: https://bionic.fullstory.com/rust-at-fullstory-part-2/
I'm planning on doing something similar to this article, crossing FFI boundaries with some light managed serialization. Should make it easy to bring in new languages quickly, and we really don't send THAT many messages so I'm not horribly worried about performance.
Anyways, that's what things look like for the moment. What does this all look like in the end?
Well, basically, if you want to write software for a sex toy, on any platform, desktop/mobile/web, you should be able to, and it should use mostly the same codebase.
Well, basically, if you want to write software for a sex toy, on any platform, desktop/mobile/web, you should be able to, and it should use mostly the same codebase.
It's a long path to get there, but if you haven't noticed by how little actual sex toys are mentioned in this thread, I'm far more in this for the architecture challenges than I am for the dildos. :)
But I'd also like it to be over soon so I could get back to working on feature additions to the Game Haptics Router, Syncydink, etc...
Intimate Technology UI/UX is also super fun to work on, and while I'm happy to wallow in SW Arch for months at a time, I miss UI/UX work.
Intimate Technology UI/UX is also super fun to work on, and while I'm happy to wallow in SW Arch for months at a time, I miss UI/UX work.
If there are things you'd like to see in the library or apps built with it, please let me know! Reply to tweets, DM me (DMs are open), hop on our discord where I ( @qdot) am pretty much constantly: https://discord.buttplug.io
Even if I'm too busy to work on stuff, we have community that are working on different projects that can help.
If you just watch this account you might think this project is just me tech navelgazing, but there is an active community working on games, audio/video programs, etc.
If you just watch this account you might think this project is just me tech navelgazing, but there is an active community working on games, audio/video programs, etc.
