btleplug VS deldo

You're absolutely correct! I mention this elsewhere in the documentation even. Buttplug really is just a userland HID manager at its core. The only specialized part is the context of commands we send to devices.

The original plan (and it may still happen, who knows) was to figure out a way to chop off that top message layer and create a generalized system for doing exactly what you've said. That was going to be called 'deviceplug', and it's why btleplug is under the 'deviceplug' org on github (https://github.com/deviceplug/btleplug). I've just never gotten around to it because I'm not quite ready for the additional support burden yet.

All that said, Buttplug is also a haptics experimentation project aimed at finding out what it's like to create a way to communicate about a very specific type of touch via technology and programming. There are specific goals within the project related to that, but the amount of tech required to actually pull that off means I end up with what basically amounts of a fleet management framework. :)

In case someone is curious: https://github.com/deviceplug/btleplug/pull/279/files

Is something wrong with https://github.com/deviceplug/btleplug or you haven't found it? You could also use bindings to platform libraries like https://github.com/microsoft/windows-rs and https://github.com/rust-mobile/ndk if btleplug doesn't have something fundamental to you.

One of the worst/best parts of buttplug is that I ended up needed to maintain my own Bluetooth LE library: btleplug (https://github.com/deviceplug/btleplug).

Worst because working with bluetooth is always THE WORST, best because of the submissions and community that've grown around it.

There's 2 types of PRs to btleplug:

- People going "here's a PR but uh, why is the library named btleplWAIT WHAT"

- People going "here is a PR specifically to fix something in Buttplug thank you"

"In its dev branch"

I've always been annoyed at the cross-platform story for Bluetooth. GATT is one of my favorite protocols because it is so simple, but writing simple code against this simple protocol is _not_ portable:

iOS and macOS have CoreBluetooth, Linux has BlueZ, Windows has Windows.Devices.Bluetooth and Android has android.bluetooth.

I've seen a few projects trying to fix this, like https://github.com/deviceplug/btleplug, and I hope one of them becomes production ready.

But, that's an ongoing problem. In terms of "done", I think the next big milestone will be mobile app support. We work on mobile web browsers in a couple of different ways, but Buttplug still needs app support, both native and for things like cordova/react native/etc... The biggest issue there at the moment lies in our bluetooth library (btleplug, https://github.com/deviceplug/btleplug), because getting the FFI via JNI to android is going to suck (even though I can crib off Servo's WebBluetooth impl, which worked on Android).

In Django, it is just plug and play. Admin panel and other QOL features are there for you out of the box. There are enormous amount of plugins, seriously it is insane to a point that only thing missing is controlling a fucking dildo from the admin panel (https://github.com/qdot/deldo please port this). So you will re-invent the wheel. A lot.

I've only ever seen an Emacs package to control a dildo, someone should make a Vim plugin. Emacs really has a package for everything...

I suggest seeing https://youtu.be/B6jfrrwR10k beside that many dedicated packages exists for specific tasks with pre-coocked code from https://github.com/qdot/deldo to https://github.com/purplg/hass/ passing though http://melpa.org/#/tubestatus or https://github.com/segv/sudo-make-me-a-pizza org-mode act just as glue.

Why is it that the very first thing I thought of was https://github.com/qdot/deldo