Comprehensive framework

[not_theory]

All:

I see various applications described in this forum. They seem to be a collection
of programs that are not designed to work together. So, here are the questions:

What are all of the ways programmed hardware would advance our cause?

We have key release, senario description, sensing the subject, voice control,
remote control, equipment drivers, and various types of feedback and timing.

Given some list like the one above, how would we define the relationships
(interfaces) that make sense for these devices or functions? Could there
be a framework that supports the organization and operation of these
capabilities? (think LabView)

How would we extend this to be inter-operable across machines to make a
community aware environment for safe playing?

Would we get further if the proposed project could develop a standard set
of supporting modules that others could use?

I would offer my systems experience to help create a formal definition
of such a framework if others could supply the ideas and other information.
This community discussing and modifying the definition itself would draw
more support from the larger community that just the people who are developers.

Not Theory

[cooper1337]

Hi,
that sounds interesting. I always loved modular systems.
There are two major decisions to make:

Which operating system will be used?
Since I am a linux user, but most other users will have windows, I would definitely prefer a cross-platform framework. But of course this would increase the amount of work needed for this project, and currently I have a virtual machine with windows installed, which would add more security.

Which kind of interface will be used?
There are only a few kinds of interfaces between modules:

• statically linked: All modules will have to be compiled into a big application. This is not very practical for this kind of framework
• dynamically linked: Using shared libraries/ DLLs. This is more flexible, but requires more programming skills than the other two solutions.
• stand-alone executables, which communicate either via command-line parameters, which would enable data transfer only on startup/exit, or, which would be more sophisticated, with pipes, what again requires more skills than the other way.

Of which kind of interaction did you think?
I already thought of building an open-source/open-hardware project like this, but currently there are some financial restrictions that kept me from building hardware. But I would like to participate in any project like that.

What I would require as components:

• main app1: program that controls all other components. Reads a predefined script and executes it (like Cybermistress/PC Mistress/VirMst)
• main app2: program that controls all other components and is itself controlled via the internet
• an abstract type of input device which regularly sends (or gets polled for) a list of variables, booleans (release-button pressed,...) or integers (arousal level, current time, number of blows, ...)
• an abstract type of output device which is capable of receiving a list of variables (motor speed etc.)

Any kind of sextoy would get a standard descriptor (like on usb or uPnP) and its own library to control it (the library will contain the descriptor).
Maybe there should be an additional layer between the device-control-library and the main application, which abstracts single devices like motors to something related to the effect (like "fucking machine", "vibrator") or something.

There are much more ideas about that in my head, but it's getting late. The whole idea seems to be worth further thoughts, but you should not underestimate the work only one of these components will require!

[not_theory]

Cooper:

What makes a project of this sort so intimidating is diving into the
details so early. Doing so does two things. First, people who mght
be interested in helping will have no chance to participate if they do
not understand what we are saying. Second, if the scope of a project
is not settled down, we (programmers) tend to make allowances for
doing things several times until the people who will use the software
are happy. As programmers we get bagged both ways. We either, as
you suggested, over build for generality or under build to get it done.

Could you help pose an initial, general set of questions the entire group
could respond to. For example:

"What does adding a computer/software to the scene do that we desire?"
or
"Are we looking to the computer for CONTROL, DECISIONS or SAFETY?"

You are probably better at this than I am. I am new to this scene.

not_theory

[Jadit]

My understanding for modularity in this sort of subject, is that we would still have a bunch of different software. However we can generalize the input and output. Input is naturally starting parameters, like "timelock.exe -hide -time=1:20:0". Output is usually what the application is expected to do, like play a sound, shutdown computer or something else. There are already some applications that support starting other applications through its events.

By generalizing it means that we agree on certain parameters, for instance:
-hide <- would make the application start invisible, possibly just close when its "output" is done. This would mean that applications don't need to invent their own spellings of same things, like "-invisible", and all applications using the same rules would naturally work together. But it's up to them or their config to call each other. They might search for known software modules and use it if user has it. I don't know.. this topic is very wide and can be made complex if not careful.

This would also mean that there are different compilations for each operating system, but isn't that unavoidable anyway. There are many programming languages that can compile software on any system with no code changes.

[cooper1337]

Input is naturally starting parameters, like "timelock.exe -hide -time=1:20:0".

That's only one possible way to communicate between processes. It's the easiest, but also the least flexible, since you can only deliver information on startup/exit.

Output is usually what the application is expected to do, like play a sound, shutdown computer or something else.

I'd rather say that the output is the information that goes back in the opposite direction as the input. For example call "sensor.exe COM1" to ask for data from a sensor connected to comport 1, which in turn gives a value (via exitcode or pipes) which represents the sensor state.

What you are declaring as "output" is not part of the interface anymore, since it will implementation-dependent.

By generalizing it means that we agree on certain parameters, for instance:
-hide <- would make the application start invisible, possibly just close when its "output" is done. This would mean that applications don't need to invent their own spellings of same things, like "-invisible", and all applications using the same rules would naturally work together. But it's up to them or their config to call each other. They might search for known software modules and use it if user has it. I don't know.. this topic is very wide and can be made complex if not careful.

*agree*

This would also mean that there are different compilations for each operating system, but isn't that unavoidable anyway. There are many programming languages that can compile software on any system with no code changes.

It is usually a bit harder if you want to code a GUI. But I'd definitely leave this to other people, I'm fine with command-line tools.
But that is the big advantage of modularity: One codes a CL-tool that does all the work, and someone else can code a nice GUI, and since the interface is well defined, both can be used together (in theory ).

Could you help pose an initial, general set of questions the entire group
could respond to. For example:

"What does adding a computer/software to the scene do that we desire?"
or
"Are we looking to the computer for CONTROL, DECISIONS or SAFETY?"

Do you want to create such a framework or do you want an abstract discussion on how good it would be?
If you have questions, you maybe should ask them yourself, I don't think "being into the scene" is necessary to express oneself

If you are not specifying what kind of framework you are thinking about, you can't expect anybody to tell how they think about it. I do have an opinion about it, because I already have some sort of picture in my mind of how it might work. But that is only because I'm often thinking about it myself.


My personal opinion about the questions you stated:

I'm looking for all three: control, decisions and safety.
I like to give up control, but I don't trust any human being enough to give it as much power as I would give to a program/computer/machine (assumed it is built someway failsafe). I was always thinking about what kinky stuff I should do in a session, so I started with rolling dices, then I programmed a simple randomizer-tool, then a more sophisticated one and then I found VirMst, which is sufficient for the mental part. But I want more, so I plan to build some hardware that can be controlled by the program, e.g. to check whether some tasks have been done or to force some corporal punishment.
All this would be more comfortable if there was some standard way to access these toys. Since some of those ideas (e.g. http://forum.boundanna.net/board/viewto ... 470#p40470) require real-time control, I decided that using a relay-card, where it would be easy to define a standard for, is not sufficient.

"What does adding a computer/software to the scene do that we desire?"

I don't really know how to interpretate this question. It simplifies the release and gives more opportunities to solo-play, since you have a "semi-intelligent" dom instead of a "dumb" ice-release. It adds random elements without jeopardizing safety.

[not_theory]

Cooper:

After all that you really did say what you were thinking. It gives me a
place to start. I will attempt to create a document off line that I can
send you to look at.

not_theory

[not_theory]

All:

My initial thought for the framework would be an agent based model
with an environment supported by both local and remote servers.

This would permit individual components to access and publish information
in a simple fashion. The components need only be network attached such
as a camera, or a process control computer. Control components, and others,
could easily monitor the situation and post requests for other components.

This would also solve the cross-platform issues. It could even permit
someone to offer scenarios as a service. Someone could offer to monitor
a scene and trigger a safety response. For example, a voice message
could be posted to one of the servers when the volume exceeds a threshold.

Each agent would be implemented as it makes sense for the device being
programmed. Most of these would essentially implement a wait loop or
a long wait task swap, keeping in mind that a second is a LONG time.

An agent can implement a speech to text facility and log it to a server.
A safety program could scan for a special word and send shutdown commands.

One of the local servers could be Xserver like so agents can get the users
attention on start up.

A company called Phidgets has an interesting array of server based sensors.

I hope this is a little less abstract.

not_theory

[cooper1337]

Hi,
what you are thinking about is of course possible, and it's the most flexible one (and I didn't think about this... *grml*), but it will be a lot more work if you want to build it robust.

The Infrastructure

Now I think I may understand your question.
What you are thinking of might be a real overkill. Most people will use the tools only in sessions, where you don't need anything running in the background all the time waiting for connections.
For those who want to be controlled all the time, a hierarchical structure might be more interesting. This would represent a real master (a program like CM or VirMst), which makes decisions and uses other programs (e.g. the driver for a shocker to punish the sub). Since those programs will only act on command of the "master program", they don't need to run all the time.
In both situations, additional tools will only be used under special circumstances (start of a session, punishment for 24/7 subs), so there should be an interface for local communication.

For those who want to be controlled via the Internet, the master-program can be replaced by a network component which exposes the local interface to the web either

• as a webserver, so that everybody might control it
• as a p2p socket (UDP?) connected to only one master/mistress
• as a client socket that connects to a "scenario server" or something. This might indeed be very interesting for things like competitions or so . But I don't know if everybody would like this.

To the more technical parts

I don't know why you would want to use an XServer for this, normally you would use a toolkit like Qt,GTK+,wxWidgets...
I'm not familiar with using XServers. It might be more flexible, but since one normally likes to have one single application to control the whole system, I don't think that this would be very practical. This is not some sort of remote-administration, although some might also want to incorporate this.

I only took a short look at Phidgets, but it seems heavily overpriced. I have to admit that the API might be a bit more comfortable and event-driven, but do you really want to pay 77$ for a board that simply gives you 8 outputs, 8 digital inputs and 8 analog inputs?
You can get a whole embedded system which has a lot more features for half the price, which means that you already have the processor on the board without the need to attach a pc to do the calculations...
And if you are not familiar with embedded systems, you can always buy an Arduino (for less).

My idea for the framework

(I will introduce a few names for the components. If you have better ones, feel free to improve mine )

There is a hierarchy including the following components

• "master": Program which is either programmed by a script or controlled via the web; it decides what to do
• "tool": a small program only invoked when used by the master; normally used to control external hardware

The tools will be registered in some local database (I'd use a simple config-file). They will be divided into categories:

• "actors"
  • "punishments": everything that hurts (spanking machines, e-stims, ...)
  • "restraints": everything that restricts (magnetic cuffs, ...)
  • "rewards": things the sub might want to get (again e-stim, opening the safe that contains the key to the CB, ...)
• "sensors": everything that gives information back (are the cuffs really closed? how many blows has the slave already done? ...)
• "data in"/"data out": everything that cannot be interpreted by the program, but should be stored/transferred (proof pictures, config files for other programs, ...)

Actors are either on/off ("boolean"), or they will have some internally defined "strength", e.g. how hard the spanking machine spanks. The value of these ones (lets call them "integers"), will be set as a relative value (0-100% or so) by the master. This will make the physical strenght independent of the script used by the master, so that it can be more easily adjusted to the personal tools.

The sensors can also give information either as a boolean or integer.

All those tools will get a sub-category which identifies its purpose ("estim", "spanking machine" etc.), so that it can automatically be identified.

The master will either totally replace a dom for solo-play, or will enable remote access to the tools. In the second case, the whole database of tools will be scanned and an human-readable version of the interface for the whole available tools will be exposed to the other user, so he/she is able to control the tools. Additionally, it should be able to add some restrictions (automatic release after 4 hours, maximum power of estim, ...).

[not_theory]

Where to begin?

I believe your plan and the framework I proposed could both achieve the
same result for what you are proposing. Our experience, though, leads
us in different directions. In my experience most implementation problems
are created by an unspoken (undocumented) expectation. For tightly coupled
synchronous applications, robustness is generally the result of one person
doing the bulk of the development and coding. Systems that are less tightly
coupled tend to be able to run even when parts are broken. Your assertion
that this approach takes "a lot more work if you want to build it robust."
is not what my experience shows.

Most programming environments, and the supporting operating systems,
support network connections. It has become a standard in many environments
with large numbers of computers, yet available for communications between
programs running on the same host.

In your plan the master program would hold the state of the ? scene ? internally.
You were proposing a set of files, and some hierarchy for the data. I am proposing
a database and server combination. Your idea for creating a hierarchy of commands
and values, like a segmented .ini file is what I would propose.

I have build an application that accepts requests, from large companies, and does
some analysis using NOAA and Google datasets. I return my findings either in an
email or py posting back to their server.

Consider the situation where I would to build an infrared scensor to detect some
specific body heat. You and I would have to collaborate closely to allow your spanking
machine to adjust its rate to maintain a constant temperature. I am attempting to
open the process up so that both of us can make our own implementation decisions
and still have an operational system. One of the goals I am trying to achieve is
increasing participation and innovation.

Your sensors could easily post data to a server. The server can log and share it.
Your sensors would implement their own data items but use the same basic grammer.

Your actors could be implemented with either pollicy or with an asynchronous callback
(imbedded server) approach. The server could be build to perform event publishing
is support of agents.

The master program, or programs, would then be implemented as actors which
query, decide (process) and post instructions back to the server.

---------------- later ------------------------

[not_theory]

-------------- continued ----------------------------
SORRY for the spelling mistakes above. I am always rushing to avoid a timeout.

A final advantage to the server approach is the ability of a specific componenet
to upload a script (driver) that would be run on a trigger. Servers perform this
sort of work naturally. This would permit a standard apporach for scripting
and having scripts uploaded.

The Xserver idea is simple. In most systems with user interfaces the main
program calls or posts events to ?widgets?. But if the display device is not owned
by the program this doesn't work. The Xserver is simply a server program that
owns the screen, keyboard and mouse. The application is started with the name
of the server to use. Events then become requests and input is a response.
Think of this as a form of VNC where the owner of the screen, the remote system,
accepts input from the local system you are sitting at.

This way one or more screens may be placed where appropriate and the server,
master program, can push data to and get data from the device.
================================================================

cooper1337 -- at some point we need to check back in with others. I hope we
not scared anyone away, as I mentioned in my second post.

I hope I have not put you off, because you might be fun to work with. While I
don't know what I could contribute to your effort. I can provide such a server
if there is some demand for it.

not_theory

[cooper1337]

For tightly coupled synchronous applications [...]

Well, I wasn't thinking of something that easy...
I'd have used pipes, but local (or remote) sockets would do the same job. I'm just saying that e.g. having multiple connections adds a lot to the complexity of the whole system (mainly the thread/resource management).

Most programming environments [...]

Well, I'm not familiar with them, I still use command-line tools and a simple editor.

Your idea for creating a hierarchy of commands and values, like a segmented .ini file is what I would propose.

Consider the situation where I would to build an infrared scensor to detect some specific body heat. You and I would have to collaborate closely to allow your spanking machine to adjust its rate to maintain a constant temperature.

Not exactly. The spanking machine will be listed as "actor", the infrared sensor as "sensor". The master program will simply be designed to activate "actor" as long as the sensor value is lower than "80%" maybe. If you want to add a "hornyness"-sensor, you can just replace the one sensor component with the other sensor, and the configuration for the master will be exactly the same.

My basic idea is, that some part of the program has to know the scene to act accordingly. If there isn't, configuration for scenarios will get very difficult.
The master is the only one really "interpreting" data, so it is the only component that actively polls for it.

I just don't like a model where everybody can send messages to everyone else. If the scenario doesn't include using a temperature sensor, there is no sense in the sensor sending its data to the server. If the server wants to know the temperature, it can ask.

Your actors could be implemented with either pollicy or with an asynchronous callback (imbedded server) approach. The server could be build to perform event publishing is support of agents.

I'm sorry, but from here on, I can't follow you. I'm not an expert in any kind of distributed systems, so you have to explain this a bit.

This way one or more screens may be placed where appropriate and the server, master program, can push data to and get data from the device.

Are you really suggesting using multiple screens for this? This is not intended to run an industrial complex

cooper1337 -- at some point we need to check back in with others. I hope we not scared anyone away, as I mentioned in my second post.

Well, often people just start to think about how useful a program would be if they have it in front of them
But some feedback from other kinksters might be interesting, it doesn't have to be as technically as ours!

I hope I have not put you off, because you might be fun to work with.

Thanks

[not_theory]

All:

Consider a simple proof of concept for the server approach:

1. Using English, create a set of simple definitions, for a few specific actors, sensors,
and the master components of a system. Describe the inputs and outputs keeping
it simple. Describe some conditions the master would respond to and what the
response would be.

2. Using only the small set above, describe how an abreviated (sample) scene would play
out. From this produce a list of sensor inputs with the time from the scene start.

3. Implement a simple server on one of my development machines. Provide actor,
sensor, and master sample code.

4. Implement actors which essentially log their inputs to a file. Implement scensors which
read their inputs and emit their reading at the appropriate time by using a wait.
Implement a very simple master that cycles on a short interval, logs its activity and
emits its decisions.

If the work were done in php, each of the modules could be started in their own command
shells at the same time. The job that starts the test would also initialize the server.

This proof of concept would be able to answer questions about complexity, effort, and
robustness. The server should be able to produce a status report that can be viewed
on a browser and refreshed periodically. We should be able to see the scene play out.

PROBLEM - I can do items 3 and 4, but would have to work with someone for the first 2.
I believe the package could be put together over a weekend once step 1 is done.

not_theory

[cooper1337]

The simplest definition would be:
Every sensor can send a value (a number), representing the hardware state.
Every actor can receive a number.

Example:
Sensor 1: "Orgasm Sensor": sends "0" if no orgasm has ocurred yet, and "1" if one has ocurred.
Actor 1: Milking machine: sets the speed according to the number (0-100)
Actor 2: Electric handcuffs: are closed when they receive nothing or "0", open when they receive something other than "0"

Master script:

Code: Select all

send "0" to actor 2 (close handcuffs)
start loop
	send random value (0-100) to actor 1 (change speed randomly)
	wait 10 seconds
end loop if receiving "1" or bigger from sensor 1 or if time exceeds 1 hour
send "1" to actor 2 (open handcuffs)

The input from sensor 1 would look something like

Code: Select all

0 0 0 0 0 0 0 1 1 1 1 1 1 1 1
             ^ orgasm

This proof of concept would be able to answer questions about complexity, effort, and robustness.

Proof of concept almost never tells anything about robustness
But I'm very eager to see your results