It goes without saying that the structure of Sivelkiria requires a special approach to organizing interactions between module developers and operating system developers. It would be naive to believe that operating system developers could immediately create a set of interfaces needed for all future usage scenarios. Universal compatibility requires continuous two-way collaboration between OS developers, who are responsible for defining Sivelkiria’s API, and software developers who use this API actively.
Every interface is assigned an integer version number. When the version changes, new entities can be added to the interface; however, existing entities cannot be removed or altered.
All versions of the interface are compatible with each other. If the interface implemented by the calling context has the same version number, their compatibility is obvious. If the object implements a higher version of the interface than the user expects, then some of the data and functions provided by the interface are simply not used. Finally, if the object implements a lower version than expected and the user context tries to access entities that are not known to the actual object, the OS uses default implementations. These default implementations employ algorithms that exist in the previous version of the interface. For example, if a higher version of the ‘Article” interface has a newly added ‘Advert text’ field, which can be used in banners that link to the full text of the article, the default implementation can extract the first sentence or the first paragraph of the article. Another approach is to return special ‘Not Implemented’ values or exceptions in response to attempts to access non-existent data, shifting the responsibility for processing such restrictions to the calling context.
Similar rules apply to versions of module prototypes. Since the primary function of the module is to implement data interfaces, we will not elaborate on this any further.
Interfaces are distributed centrally through a repository supported by a team of operating system developers. New versions of the interface can be created when updating the operating system. No other repository would be allowed to distribute the interfaces as this would eliminate the global compatibility Sivelkiria strives for. The only exception would be private corporate repositories which can be used if some interface’s existence is a commercial secret. However, such interfaces can’t be used outside of the organizations that develop them for internal use.
The modules can be distributed both through the repository supported by the OS development team and through the repositories supported by third parties (commercial software developers, open source software developer communities, corporate servers, etc.). The repository supported by the OS development team is considered the ‘root’ or ‘main’ one as it provides some unique services.
For example, when new module versions are uploaded to the repository, their testing is executed using module, integration and performance tests. The library of these tests is maintained, and new ones can be added to it at any time. The test results become available to both the developers and the users. When new tests are added, they are applied to the older versions of the modules available in the repository as well. All tests provided by the main repository are available to all developers, the only exception being preventing module optimization for specific tests which would make testing ineffective.
In addition, the main repository collects information about all modules available in other public repositories and tests them whenever possible. However, direct downloading of such modules is not allowed. This allows users to have all the information about available modules in one place. It also allows software publishers to attract more users to their own repositories (markets).
Finally, the main repository helps to carry out arbitration in case of disputes. E.g. when third parties distribute unlicensed versions of the software. It is impossible to create a third-party repository without registering it in the main one. The same rule applies to private corporate repositories. The main repository support team has the authority and ability to block those who violate the collaboration rules both at module level and at third-party repository level.