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 a version number consisting of two parts, a major and a minor one. When the minor version changes, new entities can be added to the interface; however, existing entities cannot be removed or altered. Major update versions are released when the interface requires significant alterations.
All minor versions within the same major version are compatible with each other. If the interface implemented by the calling context has the same minor version number, their compatibility is obvious. If the object implements a higher minor 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 minor 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 minor 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.
Major versions of interfaces may or may not be compatible with each other. Let us consider an example: the interface of ‘Point position 1.0’ uses Cartesian coordinates for points on the screen but changes to Polar coordinates in version 2.0. If the currently implemented interface version does not match the expected one, the operating system could convert Cartesian coordinates to Polar ones and vice versa.
However, masking of the actual version number is not always possible. For example, if the interface of ‘Melody 1.0’ represents a tune using sheet music notation and version 2.0 uses audio recording, there is no way to establish a relation between these music representations, because the same tune may be played using different instruments, and the recording may contain sounds that cannot be committed to paper. Similarly, if the interface of ‘Note’ was originally developed for text content and then adapted for handwriting, it would be difficult to convert one to the other. A handwritten note may contain drawings, while the text may contain invisible characters (e.g. soft hyphens). Finally, city maps are traditionally represented in two dimensions, but that is often not enough for big cities with multi-level junctions. Obviously, converting these formats would require a special approach.
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.