Web services and OpenGL oh my!

Interesting title you might say of this post. Given that OpenGL is far more related to desktop applications then servers. What I'm actually referring to is two different sets of projects. For OpenGL I am referring to DOOGLE my little GUI toolkit written in D. With regards to the web service, I can't say too much at this point about the purpose however I can for some of its elements.


Web service:
To start I want to say this is the second iteration of this web service I've been developing. The first time it was php based. It was designed to run basically anywhere with little to no requirements. This time I am going over the top. It will take multiple instances of the server just to operate.

Elements I have to consider:

• I need to be able to run untrusted code. That I can log. Both on server and on client.
• I want session storage to be in database so it can scale with load distribution.
• Target audience will have access using javascript and most likely not be on mobile.
• Extensibility and social is key to success of this service.
• I want whole portions of site to be disableable and configurable.

What have I done to make this possible?

First off I am using D specifically vibe-d as the web server library. This library is lacking in a few things to allow this. First off no relational database support. Big problem. Most likely OpenDBX to the rescue. There is however MongoDB and Redis support. So NoSQL solutions are sorted.

Load distribution is very much not ready to be used. Because of this it'll most likely need to be backing e.g. Apache to handle that or some other form. Content distribution network should also be included for any semi static content like images, video ext. Most likely backing it by MongoDB and pushing that into CDN. That way if its not in CDN it'll hit DB and get it. The reason DB is required is for scalability.

There is no configuration system in vibe-d. Huge problem. However JSON and BSON support is there. Perfact can easily create one. The configuration system has to be highly flexible and contains pretty much any configuration possible. Problem though is reconfiguring a server instance requires restarting it. Mainly because changing anything like ports or binding addresses would mean a take down of socket. This would reinitiate a lot of things so not worth it. Disabling of whole sections of web service is done not by configuration but at compile time. So big win on performance, big issue for changing at runtime.

Now running code safely is a tricky business. You can jail it under linux but its still not that safe. My choice is to use Docker. Docker is a linux container that runs in software not at hardware level. So its perfect performance wise. You can also set a max on ram and cpu. There is also ability to create and trash whole instances of a model that you produced ahead of time. This is the main reason I choose D. D is at the system level. Languages like php are not. They are slow I can't go grab the pipes to a process so effectively.
I want to support many different languages in these VM's. However because at current dmd requires gcc essentially I'll be pushing out a native one as well possibly python and java into who VM's. So the native one would possibly include things like g++ / gcc, dmd, nasm.

This project will eventually be open sourced. However I cannot at this time nor say its end purpose.

DOOGLE:
This project is a rather interesting one. It has developed in two phases so far. First being it originated after porting OOGL to D. My ported version (D_OOGL) was an attempt to get a basic OpenGL wrapper in D that I could transmute to a game engine. I found it to be not utilising the power of D however so a rewrite was in order. Then we had a lot of hubber on the forums about gui toolkits and I had a played and see if it was doable (for me at least) to utilise OpenGL for gui controls. It was more than doable I saw.
Not long after DOOGLE came about.

So what exactly is the current status of the project you may ask. Well that is a good question and here is my answer:
Status:

• Has a full abstracted interface between components and implementations.
• This is also reflected in windows, context's as well.
• Possible to implement majority of controls required currently.
• Currently to add a whole new implementation other than OpenGL like html5 for components and windows.
  However this opens new challenges of how to make it lightweight for web servers.
• Very basic controls of a button, image and label.
  Where label is just a wrapped around imag essentially and button is a special kind of a layout.
  Notice how the button contains "Hi I am a button!" and "Umm|" well those two things are labels. They are children of the control.
• There is an OOP wrapper around the eventing system. That when utilised with alias this you can interact with event manager class for a control as if it was the control. There is a wiki page which explains the eventing system if you want to learn more.
• Asset management is a rather big topic and quite an important one for GUI toolkits. For example on windows you have the rc compiler which creates resource files that can be compiled into an application. However on linux you don't have that luxury. So any solution I came up with had to be cross platform and rc wasn't it. The most obvious solution is compiling into the application. I personally believe in the process of preparing a D file from files. Now D's front end does have the ability to import files at compile time. My preference however is Bin2D a project I made to compile resources in. I have not yet added support for it in the asset manager.
• Now theming. Theming is an interesting topic. In some GUI toolkits its hard coded or defined in external configuration files. I personally don't like either. I have an alternative approach. Using shaders. Shaders are utilised for how does a component looks. So each platform, application and user owned can have their own shaders to suite their taste.

To view the source code that created that window go here. It has examples of things also like firing your own custom events.