##Why RPC Socket

### What is wrong with ajax
With nowadays half of the internet hanging together with ajax, it is easy to forget that ajax is just a hack in which we reuse the _http_ protocol to do something that it was not designed for. Ajax is not particularly suitable as an RPC mechanism. But then again, since ajax was the only RPC-like mechanism that browsers until recently supported, ajax is indeed what we have used to build half of the existing internet.

### What is wrong with JSON-RPC
[JSON-RPC](http://json-rpc.org/) has made the same mistake as SOAP and XML-RPC. JSON-RPC inspects the messages being sent and forces the developer to conform to a particular arrangement or even to a formal schema.  JSON-RPC adds a bureaucratic procedure at a point in time when most developers would rather remain in prototyping mode. It causes the following reaction: _Get out of my way, because I am too busy for this right now. I've got other things on my mind._

There would be nothing wrong with adding structural validation logic before sending a message, but that is rather something for later on in the project. Furthermore, there are many ways to do that. One size will not fit all. In practice, as you can see from most REST APIs floating around on the web, most applications will simply not implement any formal validation schema system at all.

With *RPC WebSocket*, you can still send whatever you like, just like with standard websockets. It is just a router module that facilitates the delivery of messages to the right handlers inside your program.

### What is wrong with socket.io
Somewhere in the future, there will probably be nothing wrong with _socket.io_. In this month of August 2014, there were at some point 600+ outstanding, [unresolved issues](https://github.com/Automattic/socket.io/issues). I personally also logged a trouble ticket for something that we can only call a bug, but I have not heard back from their _helpdesk_.

_Socket.io_ supports lots of features on top of websockets, such as support for _express_ and _koa_. They also implements numerous scenarios in which you can use websockets with _namespaces_. You can even join and leave _rooms_. I only needed the _custom events_ (=message types) and _acknowledgements_ (=rpc). In _RPC Socket_ I did not want and did not implement _namespaces_, because you can just prefix your message types with a namespace in order to create separate channels in one websocket.

In *RPC Socket* I did not implement support for _express_ or _koa_. You could as well run the websocket server on another port, or even in another virtual machine, if you are worried about firewalls. Mixing http traffic with websockets in one server process, looks like an excellent way to create an undebuggable monster.

If you combine the _socket.io_ features in unexpected ways, you may be in for a surprise. Just for the hell of it, I tried to use _namespaces_ combined with _acknowledgements_. The entire edifice came crashing down and my trouble ticket is still unanswered. By the way, I did not find any unit tests in the _socket.io_ sources that test for such combination of features. There are many other scenarios possible for using websockets than the ones implemented today in _socket.io_. I wonder, however, are they going to keep adding every possible new scenario? That could only end in a fully-fledged _disasterzilla_ ...