This is a guest post by Jonathan Gros-Dubois.
If someone wants to write a custom server, which uses its own protocol or adds a layer on top of an existing protocol, they will typically write a human-readable RFC protocol specification to accompany it. Later, people can read the specification and start implementing clients for it. Usually, the people who built the server will also implement and maintain one or more 'official' clients.
Overall, the current approach works, but it has some significant drawbacks:
As an example, the Socket.io project has published its own RFC protocol specification and this specification has formed the the basis for at least 5 different clients (note that these clients have essentially no code reuse between them):
This is the current convention for doing things and it has become a bottleneck in client-server innovation. There may be a simpler, less conventional alternative to consider:
We wanted to keep a lot of the 'nice to have' behaviours which the JS client provided (like auto-reconnect, pub/sub, auto-resubscribe, JWT auth token management, etc...). These behaviours would be difficult to describe as a protocol (would require a lengthy RFC specification), but we really wanted them to be available natively on iOS.
Keep an eye out for our android client - it's coming soon.
Special thanks to OpenLearning for their feedback and support in this highly adventurous project.
Research and development was by Lihan Li with assistance from Jonathan Gros-Dubois.