"As of 30 March 2010, OKWS is still being maintained and worked on. id=okws:releaseplan isn't very reassuring Neither is `svn co svn://svn2org/ok/okws2/devel/3.0 okws-3.0; cd okws-3.0; svn log | less`...
I don't know enough about their traffic to know how much machine efficiency would help them...
I'm still actively checking in fixes and smallish new features, but there won't be any big changes over the next few months.(2) OKWS and all services written for OKWS are single-threaded, non-blocking asynchronous processes.
All database calls still go through RPC-to-SQL translators, as mentioned in the paper.
I worked at Ok Cupid for a bit and got to see OKWS in its full glory.
Though it sounds kinda daunting from the documentation, it's actually reasonably workable.
The only thing unusual is that a _t suffix usually suggests a typedef, and I don't think you can use a type alias to define a constructor.Or their technology is poorly documented and basically an oral tradition.God help them if their lead developers get hit by a bus.I haven't looked at the API or done any web programming; I thought it was interesting what I could tell from this snippet regardless.It reads a lot like those medieval manuscripts back when the European languages didn't have so many vowels in them.
The other cool part of the stack was getting core dumps on segfaults. That way, I can run them all in one process (with ZMQ inproc messaging), or run them all in separate processes (with TCP or Unix sockets), depending on my needs for reliability (more uptime because I can deploy-and-restart one tiny component at a time) or memory usage (all in one address space = more sharing).