My project is currently steering towards developing a standard template for making datatype extensions for spacebrew.
In my imagination, this template would allow the following things:
- Quickly assembling a datatype to be used across different platforms supported by spacebrew, especially OF, Processing and Javascript.
- These datatypes would be mostly constituted of protected name variables that already exist across the languages: int, float, boolean and string.
Example:
Let's say I want to make a datatype that would hold 3 values. It could be used for defining positions/directions in 3D space. The equivalent in OF to ofVec3f or in Processing to PVector.
The values this datatype would hold are 3 float types of names x, y and z. These values would be sent through spacebrew via JSON and for the purposes of development it would be called vec3. In JSON it would be structured like this:
{
"x": "10.0",
"y": "13.25",
"z": "2.34"
I could then go to my OF and Javascript templates for making SBX datatypes and make a vec3 that would look like this in both.
Things it should do:
When JSON messages become more and more complex, the tendency of broken data being sent increases. This is particularly sensitive in Javascript, which will accept the JSON as valid. Other JS libraries however, will not.
This is what happened when I tried drawing D3 Voronoi getting data from Spacebrew. As soon as a JSON value would mistakenly be updated as NULL, the library would break and together the functionality.
2. Provide methods for extracting data:
2.1. First possiblity: on the fly conversion
JSON data is formatted as string. In the OF and Processing templates, SBX should have methods to extract the data from the object. Something that (may) look like this:
int foo = customVec.getInt ("x");
class vec3 {
int getInt ( string request ) {
return value[request].asInt();
}
}
This has the advantage of being easily replicable throughout the template. It has the disadvantage of being less intuitive than the following.
2.2 Second possibility: internal datatypes
Which would have the variables be built inside the SBX object, sort of like this:
And have the conversion be called in a loop that would have the object be "updated". This will make for a simpler solution for beginner users to just use SBX types, but will also make for a more complex template.
3. Protect the JSON format
JSON is very flexible. If someone were to do this:
The JSON would instantly add it to its paramters:
"x": "10.0",
"y": "13.25",
"z": "2.34",
"foo": "4.5"
This has a great chance of throwing an error depending on the parsing method in the receiving entity. The template should also validate the access the user has from outside the object and throw an error if something like this is attempted.
Current Status:
I started developing from the OF side for 2 reasons: it is what I'm most used at working on and C++ tends not to be a very forgiving language. I figured making a template for C++/OF and simplifying it for JS and Processing would be a better approach than, for example, starting in JS and trying to adapt it to C++.
Future Steps:
Talking to Brett, he suggested keeping it very bare bones, so the entry into SBX is easy. The basic template should only include the stability features mentioned above and a couple of helper functions (such as "print to screen"). The current suggestion is overriding the sb Message class and adapting it from there. The clear advantages would be using the exact same syntax for custom and non custom variables (seen that I may want to use range, bool and vec3 in one single application).
This is what I'm currently working on.
Future future steps:
It would be awesome to have an "SBX generator", where one would input the values they need and it would instantly generate the extensions for them in the various languages... need to discuss ups and downs of this possibility. Main reference: Protobuf.
