Actually, yes, I consider this very easy. I'm not trying to brag, but this part isn't complicated as long as I can beat probable performance problems. There are design challenges, but they are not intractible.
The day you see 3D games and simulations written in HTML, is the day I award Tilly the Turing Award. Nah, man, you missed the whole point of why OpenGL was important :)
InterruptsAre you familar with the GLUT main loop? Interrupts can easily be processed in "C" code and handed back to the consumer as commands over the pipe. This includes motion events, keyboard events, etc. Just because the API supported something when it was pure "C" doesn't mean it can't support this over an IPC boundary. We are just extending methods to work over such a boundary.
Debugging hooksWell, OpenGL itself doesn't have a lot of debugging hooks either. Essentially, the most common bug is the well known "BlackScreenOfDeath", where your camera points off into space and there is nothing you can do to figure it out. I'm proposing a packet-level (essentially) system to interface to OpenGL over named pipes. That's all. Sending OpenGL commands out of order will be the problem of the caller, though debugging facilities are certaintly being coded in. Since both sides will have debug modes that echo all commands printed to the pipes to the console, I can see the exchange between the two sides fairly clearly.
So, as alluded to earlier, I decided on the named pipe approach not Expect... Expect looks to be a decent module, but if I use two named pipes, I get greater portability across multiple languages. Performance is still a concern, but if I use display lists, I think I can get decent performance regardless of the calling language. I already have a very clean OO Perl interface which I am currently using to debug the named-pipe system and the event handlers. Parsing, since I am keeping the protocol clean, will be kept to a minimum.
I have some rough documentation here, it's still not linked from the main page of my web site: Engine. My theory as to whether it would be possible to drive an OpenGL program from Bash is a little theoretical, I at least want to try it before claiming it is possible on my home page. I definitely will be able to code up some OpenGL support (sans-C-bindings) for many languages that normally cannot do 3D graphics.
Anyhow, check out the link, I'll probably some more coded up later this week to where I can show some code -- if I'm not doing my taxes, that is :)
again, doc link: here -- it's very rough. Be kind to it!