The devices that run the Sivelkiria operating system can interact via network using object interfaces provided by it. Since any objects that the programs work with are represented through these interfaces, it is possible to exchange any data and calls between any programs and devices ‘out of the box’, without additional effort on the part of the developer. The interaction between devices that are both running Sivelkiria can occur at different levels:
- Stored data level. When using a device, the user can directly access data stored on another device. The use of the same interfaces for objects on disk and in RAM makes it possible to track and to resolve potential shared access conflicts as soon as they occur.
- Data level (regardless where it is stored). For selected (or all) objects, syncing between multiple devices can be enabled, either locally (over the network) or via a cloud server. Access to an object always guarantees obtaining the actual copy, and synchronization can be performed in the background, inclusive of the access itself (e.g. when the full contents of a large file are still being extracted but the requested fragments are being read from the source directly).
- State level. The state of a device (playlist, print queue, connection list, network activity, etc.) can be viewed and changed directly from another device using programs running on the latter. For example, if a Hi-Fi system located in a room is connected to a desktop computer, the user can control the volume and playlist from a smartphone connected to it over Wi-Fi, regardless of any specific modules used on both devices. Transferring a call from one device to another is another example.
- GUI level. Operation windows can be transferred from one device to another. For example, the user can use their device to track the progress of a long-running operation (e.g. a file download) performed on another device. Another example is moving a window of a corporate mail client to a smartphone inside the same network. The window can adapt to a new device. The GUI can be transferred either by request or automatically: for example, a video call window may follow the user moving within the house, and this will work regardless of the software used and connectivity method (including the scenarios where the protocol itself does not support call transfers).
Transferring the workload between the devices can be done in a few stages. For example, when a video clip from the Internet needs to be transferred to another device, the first step would be to transfer the whole window, since it would be the fastest option. The video would be streamed from the original device to avoid latency. After doing so, the device which is now playing the video could connect to the same video host, download the required fragment, synchronize the playback with the original stream, switch to the new stream and only then allow the original player device to disconnect.
Breaking down the interactions by category makes it possible to customize access control. If we go back to the example with the Hi-Fi system connected to a computer, controlling the volume or pausing and resuming the playback would be available to any of the devices in the room, but viewing the playback list or accessing the files being played could be disabled for some of them. In the case of connecting a smartphone to a corporate network, accessing the mail client could be enabled, but accessing documents with clients’ personal data, restricted.
If Sivelkiria runs as an agent under a host operating system, everything that is available to the agent, whether it is a file system, screen, audio device, notification list, and so on, becomes available to the devices connected to this instance of Sivelkiria (after applying the same mechanisms and access rights).
The network interaction scheme can be flexibly configured. For example, a device running Sivelkiria can act as a proxy at the corporate network terminal. This does not require creating a special protocol, regardless of the data being transferred, because proxying is supported at the operating system level.
Another example is using UPnP to connect the devices through infranet boundaries. Since there is a constant need for communication between devices, servers maintained by the OS development team would feature a connection establishment service available to all users. Private connection servers are also supported. This means that two devices registered on the same server can connect any time.