FFI Implementations from the buttplug-rs Rust Sex Toy Control Library to other langauges.
The library currently implements FFI from Rust to the following languages:
- Java
Our current plans are to possibly expand to the following list of languages:
- C/C++
However, for most languages, we recommend natively implementing at Buttplug Client and having it connect to Intiface Central. This approach is outlined in the Buttplug Developer Guide.
C# and JS have been moved back to the Buttplug C# and Buttplug JS repos, respectively. Usage of the FFI with these projects didn't work out for users very well, so they've been returned to being completely native client-only implementations, with embedded connections being deprecrecated in preference to having programs connect to Intiface Central.
The Buttplug Rust FFI library exposes access to the Buttplug Client API of buttplug-rs. This allows creation of both in-process (i.e. run both a Buttplug client/server in the same process, including direct hardware access) and remote (i.e. use Buttplug Client to talk via Websockets/Pipes/etc to a remote Buttplug server) Buttplug Clients. From these clients, you can scan for and get back device objects, which allow for control of devices from the language of your choice.
The usable API surface of Buttplug is fairly small. The bulk of the library consists of internal configuration, protocol translation, and hardware communication. If the FFI layer seems small, that's because it is. There really aren't that many entry points into the library itself, which luckily makes building FFI easy.
For simple type conversion purposes, the FFI layer uses protobufs. Protobufs provide a simple, fast way to deal with type differences between many languages, and due to the low frequency of message updates in buttplug (we might send 100s of messages per second in a system with multiple devices, but usually its 10s), the overhead of the conversion process isn't too expensive for us. Flatbuffers were originally considered and implemented for C#, but ended up causing developer friction on bringup. We don't really need the ability to pick out fields to parse, as we'll always be using the full message in arguments.
For more information on FFI and Rust using intermediate serialization layers, check out the following articles:
- Rust @ Fullstory Part 2
- Rust @ Fullstory Part 2
- Crossing the Rust FFI Frontier with Protocol Buffers
The actual FFI layer consists of a few exposed cdecl functions (see the export.rs file for method definitions) that serve as message passing interfaces in and out of the system. These functions should handle being called from different threads.
If you have issues or feature requests, please feel free to file an issue on this repo.
We are not looking for code contributions or pull requests at this time, and will not accept pull requests that do not have a matching issue where the matter was previously discussed. Pull requests should only be submitted after talking to qdot via issues on this repo (or on discourse or discord if you would like to stay anonymous and out of recorded info on the repo) before submitting PRs. Random PRs without matching issues and discussion are likely to be closed without merging. and receiving approval to develop code based on an issue. Any random or non-issue pull requests will most likely be closed without merging.
If you'd like to contribute in a non-technical way, we need money to keep up with supporting the latest and greatest hardware. We have multiple ways to donate!
This project is BSD 3-Clause licensed.
Copyright (c) 2016-2023, Nonpolynomial, LLC
All rights reserved.
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions are met:
* Redistributions of source code must retain the above copyright notice, this
list of conditions and the following disclaimer.
* Redistributions in binary form must reproduce the above copyright notice,
this list of conditions and the following disclaimer in the documentation
and/or other materials provided with the distribution.
* Neither the name of buttplug nor the names of its
contributors may be used to endorse or promote products derived from
this software without specific prior written permission.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE
FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.