Flutterby™! : Interprocess Standards

An awesome semi-obvious idea that will take over the world and that I have no idea how to monetize.

Over on Twitter, Eric asked:

Watching Google Go video: http://bit.ly/3NUeUW Like what I see so far - but will there be library support?!?

I looked at Google's Go (as distinct from Francis McCabe's Go! programming language) and had a similar thought: I want to see what this language can do, I've been playing with Python and SDL recently, let's port that code to Go. Oh. Wait. No SDL bindings...

However, another realization: Processes are great ways to compartmentalize, and interprocess communication via pipes can be relatively cheap if it's implemented right. Why not make the GUI front-end one process in a language I'm familiar with that's fast and cheap, and write the back end that computes the (in this case) physics in Go? I could set up a pipe to pass data structures back and forth and... How should I serialize the data structures?

Back at Pixar I wrote a system for image output that had an API for image output. One side would say "the pixels are coming down the pipe as (signed|unsigned) (double|float|int32|int16|char) in (little|big)endian byte order" (the endianness was either defined, or native), the other would say "I want them in this format", I think quantization happened upstream anyway though there was probably some of that, and the library figured it out.

It could take multiple inputs, via network or pipe, the senders could even say "I'm sending this XY chunk of the image" and the receiver could say "buffer it and give it to me in scanline order." So you could be processing one portion of an image on a little-endian machine, another on a big-endian machine, and writing a driver for a format TGA was a matter of saying "give me scanlines in Red Green Blue Alpha order, throw out everything else", RLE compressing them and stuffing them to disk.

The flaw that I know of in it was that Tom Lokovic was, at the very time I was writing this, working on deep depth buffers, and my system only handled a fixed number of samples per pixel. But I think it got everything else mostly right (I'm sure Mark or the other Tom will drop in here to point out ways that it's been a beast, and given that the latter has used what I think is my code for a critique of coding style, I'm prepared for that).

The world needs a similar standard for interprocess calls. It's not XML, I've built a distributed system using it and that's way too expensive to parse. It might be JSON, but I rather think it's something binary. I also think it handles fairly complex data structures and has a notion of mirroring structures and persistence of objects at the other end.'

It is both a wire format and a set of libraries that provide an API that someone would recognize whether they were working in C, C++, C#, VisualBasic, Python, Ruby, Perl, Lua, or Google's Go.

And I think it'd be fun to write, but I don't have anyone to pay me to do it and I think it'll also need some names and/or applications big enough to push it so it becomes a standard. You listening, Google?