Below is the description of some other principles on which Sivelkiria is based. Although they are secondary to the ones described above, they are nevertheless important enough to be highlighted.
- There is a special network protocol for communication between any devices running the Sivelkiria OS. All data available through OS-defined interfaces can be serialized and transmitted using this protocol. In this case, the operating system creates a proxy object on the other end of the line. All actions applied to this proxy are transferred to the machine which has the source object and are processed by it. This operation is completely transparent for the object consumer and does not require creating separate protocols for each task. This makes it possible, for example, to use an image viewer program running on one computer to view files that are located, being generated or being downloaded on another computer. This also makes it possible to transmit data through devices. For example, data can be transmitted from a smart watch connected to a smartphone via Bluetooth and sent to a computer via Wi-Fi even if the computer does not have a Bluetooth module to connect to the watch directly. The context of this data can be recovered without any additional coding. Since all data interfaces have a clearly defined purpose, the operating system can apply appropriate processing when transmitting data. For example, when video is streamed, minor packet drops can be ignored, but when text data is transferred, such packet drops are not allowed.
- Data interfaces can use each other to facilitate code reuse. For example, an ‘image data’ interface may include ‘image dimensions’ elements.
- Data interfaces can be inherited, reflecting a transition from the general to the specific. For example, the ‘Raster Image’ and ‘Vector Image’ interfaces are inherited from the ‘Image’ interface. In the contexts where the image type is of no importance, a more general interface can be used.
- Data interfaces can implement other interfaces by definition. For example, the ‘Directory Contents’ interface contains data in a special format (number of elements, name and type of each element, size, description, and so on); however, this data can be extracted using the ‘Data Table’ interface and pasted into the table processor. Each module implementing the ‘Directory Content’ interface does not need to re-implement the conversion algorithm. Instead, conversion will be done by the operating system (or a specialized module it calls) as part of supporting these interfaces. This allows the use of the data object in any applicable context.
- During data exchange, the interfaces store necessary supplementary information, such as the description and source of the parameters being measured, units, currencies, etc. For example, image size, when provided in pixels, won’t be confused with screen size given in centimeters. A translator application is guaranteed to get the information about the language of the specific word passed to it. This will help to avoid ambiguity.
- The module-based design and OS with resource management functions (threads, etc.) allow significant alteration of the system’s behavior with a simple module replacement. For example, to solve highly specialized tasks, the system can be equipped with a task scheduler that implements the real-time operating system strategy, as opposed to most applications which currently use the event-oriented approach. These changes are isolated and won’t make it necessary to rewrite all application modules.
- Any hardware or software platform that can run the Sivelkiria OS has virtualization modules, making it possible to run modules initially built for other supported platforms. Thus, a module that is available on one platform can be run on any other platform, although a certain loss of performance can be expected.
- All data available through the interface is accessible through its main elements. The use of any additional information (collections of named properties, extensions, etc.) is not permitted. There is no way to determine the type of object and its origin from this interface. Thus, it is impossible to create a proprietary data exchange platform inside the operating system, and all data will be available to any context.
- The file system is designed to store objects. A byte array containing file data is a special sort of such an object. Objects in the file system can store arbitrary information — for example, to maintain a cache of frequently used data, such as a thumbnail image or a link to the codec used for reading it. The inter-object links are a form of data representation and can be used instead of absolute and relative paths. This makes it possible to achieve compatibility of stored data, too. For example, any event handler can use (and store as part of its configuration) a trigger of any type installed to the system simply by storing a link to the specific object.
- Custom scanning of the file system by modules is prohibited, except for some specific cases, such as handling user actions, or for compatibility reasons. The module can only access the objects it has links to.
- In most cases, there is no difference between the interface to the object which exists in RAM and the interface to the object which is stored on disk. Abstract access to the ‘actual file’ represented as a set of bytes is performed by the module responsible for mapping the file to a certain object (the data interface). Instead of working with abstract files, modules work with objects that can then be processed by other programs regardless of the storage format. This does not restrict the ability to access the file’s text or binary representation as needed.
- This file system supports operations that are not usually supported, such as moving parts of the content, transactions, version control, etc. File versions created by one program will be available to all other programs in a convenient interface. If a process fails when a file is being written, both the pre-overwrite state and the new version will be available and this will not require any special effort on the part of the developer.
- Rather than browsing objects located in a hierarchical structure, the user performs object search using other criteria, such as type, name, category, tags, metadata, connections to people and real world objects, relations to other objects, history, access method, source, etc. Storage organization is secondary to the user’s classification of data. For example, the user can specify that programs are stored on a high performance SSD, photos are stored on a RAID array with data loss protection, personal data is stored in the cloud and work files are automatically duplicated to all devices. The user can utilize a pre-installed object classifier or customize it as needed.
- Configuration of the type and method of representation of graphics programs is performed centrally. Global view settings affect all user interfaces (but can be overridden for specific contexts). For example, the user can specify how detailed the default technical information should be (data that interests an experienced system engineer will only distract a creative specialist), choose between the classic or icon-based menu style (this may depend of the person’s perception and health condition), select a color palette for different applications, decide between graphic or text representation of data and specify whether the WYSIWYG or markup-based approach should be used to edit text, etc. No one module is required to support all possible options, but information about supported modes is available in the repository.
- From the operating system’s point of view, everything is an object, including windows and their current state and documents stored on disk. Both documents and windows can be serialized, saved, transferred to another device or restored by the operating system at any time, although serialization and deserialization may have different meanings for different object types. For instance, in a local network the user can use a smartphone to interact with a window opened on a desktop computer. To fulfil this task, the module implementing the GUI should adapt to a change of device type (screen resolution and size, input devices available, etc.).
- There are interfaces that represent specific paradigms rather than specific application domain objects. For example, the ‘Long-running operation’ interface should be implemented by any operation that takes a significant amount of time (for example, more than one second). Implementation of this interface makes the operation controllable from any context regardless of its nature. Operations can be queued, canceled; actions (i.e. device shutdown) can be performed after their completion, the progress and remaining time can be tracked and the status of important operations can be displayed in an easily accessible widget.
- Data of a similar type is grouped together by the operating system (on one or more devices). For example, all programs use a shared logging system, making it easy to view logs in a shared table (e.g. when investigating a network outage). Another example is a list of the programs’ service requests (upgrades, conflict resolution, etc.) Messages that are not urgent will be held in a queue until the user has the time to deal with them. Messaging programs group messages from a specific recipient regardless of the channel (account) they come from. Notifications about events and publications that the user has subscribed to are collected in a common place (similar to a “wall” on a social media page). Recommendations are also located there, but have a lower priority. Subscription management methods (e.g. immediate notifications about updates from a specific author) can be configured in a general way, regardless of whether the specific content provider (social network, video hosting, etc.) supports such settings or not. Programs that send data to shared GUIs (chat messengers, etc.) do not have access to one another’s data. Thus, when using a certain function (messaging, video calling, notifications, etc.), the user does not need to think about which specific program implements it.