Each application can determine what features to support for particular functions. As a result, the same functionality is implemented multiple times, always going through a full development cycle: analysis, design, implementation, testing, bug fixes, and support. This increases expense for both users and developers. As a result, each error, no matter how typical it may be, has to be fixed in each individual program.
For example, each browser implements window rendering, file saving location dialogue, favourites bar, history tracking, network connectivity, page printing, error handling and so on. Brightness and contrast settings, as well as JPEG file support, are provided by almost every graphic editor.
If a feature is rarely used, the situation is even worse: such functionality is not implemented until the developers learn that it is required based on a crash report or users’ feedback. For example, many network applications add proper fixes for a situation where a network interface (e.g. a USB Ethernet card) becomes physically disconnected only when a certain failure occurs. Developers of task schedulers and other event-driven programs create lists of supported events themselves. As a result, rarely used events (e.g. sunrise and sunset, connectivity loss, etc.) are often left unsupported. Many office applications fail to handle connectivity issues properly while working with local network drives because such situations did not occur during testing.
We had a chance to witness a problem with an internal monitoring system in a big company. This system had its agents installed on the servers that needed to be monitored. On startup, the agent connected over the network to the server that was collecting data. When configuring the connection, you could specify the address of the remote server, the remote port, and the local network interface; the local port was selected randomly by the operating system each time. This worked well until the agent ran on a machine with an application that used a fixed local port number for some reason. After a restart the agent occupied this port, and the application failed to start. To solve this problem, it was necessary to change the agent’s code, which resulted in a significant expense, considering the cost of development and implementation in a controlled corporate environment. If the agent had used the same implementation for connectivity configuration as the conflicting application, this situation would have never occurred.
In Sivelkiria, the module system is aimed at maximum reuse of code. On the one hand, this saves developers from having to create duplicate solutions. On the other hand, wider usage and testing allow it to create high-quality solutions that can handle any typical or exceptional situation. Finally, experience is accumulated at the OS level, too: a problem encountered by a single module results in creating publically available tests that are then used to detect the same problems in all other existing solutions.