From the post:
My name is Knut, and I want to show you something really cool that I built to solve some problems we are facing here at Wooga.
Having several very successful social games means we have a large number of users. In a single game, they can generate around ten thousand HTTP requests per second to our backend systems. Building and operating the software required to service these games is a big challenge that sometimes requires creative solutions.
As developers at Wooga, we are responsible for the user experience. We want to make our games not only fun and enjoyable but accessible at all times. To do this we need to understand and control the software and hardware we rely on. When we see an area where we can improve the user experience, we go for it. Sometimes this means taking on ambitious projects. An example of this is Elli, a webserver which has become one of the key building blocks of our successful backends.
Having used many of the big Erlang webservers in production with great success, we still found ourselves thinking of how we could improve. We want a simple and robust core with no errors or edge cases causing problems. We need to measure the performance to help us optimize our network and user code. Most importantly, we need high performance and low CPU usage so our servers can spend their resources running our games.
I started this post about Elli to point out the advantages of having a custom web server application. If your needs aren’t meet by one of the standard ones.
Something clicked and I realized that web servers, robust and fast as well as lame and slow, churn out semantically interoperable content every day.
For hundreds of millions of users.
Rather than starting from the perspective of the “semantic interoperability” we want, why not examine the “semantic interoperability” we have already, for clues on what may or may not work to increase it?
When I say “semantic interoperability” on the web, I am speaking of the interpretation of HTML markup, the <a>, <p>, <ol>, <ul>, <div>, <h1-6>, elements that make up most pages.
What characteristics do those markup elements share that might be useful in creating more semantic interoperability?
The first characteristic is simplicity.
You don’t need a lot of semantic overhead machinery or understanding to use any of them.
A plain text editor and knowledge that
Takes a few minutes for a user to learn enough HTML to produce meaningful (to them and others) results.
At least in the case of HTML, that simplicity has lead to a form of semantic interoperability.
HTML was defined with interoperable semantics but unadopted interoperable semantics are like no interoperable semantics at all.
If HTML has simplicity of semantics, what else does it have that lead to widespread adoption?
[…] Another Word For It Patrick Durusau on Topic Maps and Semantic Diversity « Elli (Erlang Web Server) [Lessons in Semantic Interoperability – Part 1] […]
Pingback by HTML [Lessons in Semantic Interoperability - Part 2] « Another Word For It — September 1, 2012 @ 10:11 am
[…] we saw in parts 1 and 2 of this series, the <a> element […]
Pingback by HTML [Lessons in Semantic Interoperability - Part 3] « Another Word For It — September 2, 2012 @ 12:06 pm