OpenDildonicsProtocol
From Opendildonics.org
ODP
Need
For interoperability among sex toys and software there is a clear need for two different low-level protocols:
- One is the protocol between the computer and the peripheral.
- The other is the protocol between the machine running the user interface (i.e. IRC) and the machine actually controlling the toy.
Both ends should be as simple as possible, but no simpler. Logically and practically, it makes sense to design these so that they are as similar as possible. If you assume that the toys themselves have at least some native intelligence, it is possible to push the bulk of the protocol down onto the toys themselves.
This, at first glance, sounds like a harebrained idea, but there is a method to this particular madness. If you push the protocol down onto the devices, the simplest possible client is little more than a TCP-->toy and Toy-->TCP proxy. In Java and Python, at least, this is only a few lines of code. This being the case, getting basic support into things like chat clients is far simpler than it would be otherwise. If the protocol is kept fairly simple, it is a straightforward task for the software at one end or the other (or both) to add new functionality built up out of the functionality provided at lower layers. This can be done in much the same way TCP is built on IP's functionality.
The advantages to this approach can be substantial. The programming interface can be much simpler, since each layer encapsulates the functionality of the layers beneath it. This means that the other layers in the system never have to know anything that isn't directly discoverable. Specifically, if I am writing client software, I don't care whether the pattern generation is in the driver, or in the device -- I just know that if I feed it patterns, they get played back a certain way. The most important part of this is that it allows software people and hardware people to stick to what they're good at. I'm hoping this will work in much the same way that TCP allows programmers to write network applications without being forced to pay attention to the ugly hacks inherent in things like 802.11b and wired ethernet.
This approach has other advantage. It can be use in the internet (specially, in IRC).
