In today's interconnected world, distributed applications are the norm rather than the exception. Every man and his dog's startup is running a 100 node cluster in the cloud, your grandmother has four cores in her pocket and controls her teapot via the Internet.
Yet, the infrastructure for building distributed applications is almost non-existent. Crossroads I/O is just a small part of the bigger plan to make messaging (see message-passing) a standard and ubiquitous part of the network stack.
As for the particular goals of Crossroads I/O, these are:
Serve as a user-space implementation of the messaging layer
When striving for world domination, the first step should have the biggest possible impact. Thus, instead of implementing the messaging layer in a particular OS, we provide a highly portable user-space library. To achieve this goal we use a common implementation programming language (extremely conservative C++) and we try to keep dependencies to a minimum.
Further, to enable users of as many programming languages as possible to use the library, we provide a native C API, which is, with more or less effort, accessible from any language.
Educate developers about distributed messaging
The nature of our long-term goals is such that only popular and universal demand can make them happen; it is not possible to push them by force.
We need developers to understand what the messaging layer is, what it is good for and demand support in their operating system, networking hardware and programming language of choice.
Design for the next 20 years, and on a global scale
We design for use-cases on a global scale, even though developers are not facing these scales. Yet.
To ease integration with existing technologies, our API follows the standard BSD socket API as closely as possible. It provides extension points for future use, and backwards compatibility for today. We treat API bloat with extreme prejudice.
By thinking ahead, we can also solve the problems we are likely to encounter later, when moving on to an in-kernel implementation of messaging, hardware support, and formal standardisation of the communication protocols, before they hit us hard.
Encourage a commercial ecosystem to grow around the project
Moving beyond the phase of a user-space library is a long-term and expensive endeavour; we cannot count solely on volunteers to cover the costs. Thus, we need a thriving commercial ecosystem to fund future progress.
To grow such an ecosystem the project must be fully vendor neutral, and implement a liberal (e.g. Linux-style) trademark policy allowing use of the trademark for third party distributions of the software, as well as for plug-ins and extensions.