Multi-platform app that allows your devices to communicate
Find a file
Aleix Pol 43a24ac12e Figure out Messages.sh after code refactoring
KDED is translated again
Rename the core's pot to kdeconnect-core.pot and make sure the library
loads the catalog when it's linked to.
Provide a separate translations file for all the plugins, together.

REVIEW: 118774
2014-06-17 18:45:47 +02:00
cli Fix build 2014-06-14 16:50:54 +02:00
cmake Move the plugins into a different top-ĺevel directory 2014-06-14 16:34:11 +02:00
core Figure out Messages.sh after code refactoring 2014-06-17 18:45:47 +02:00
fileitemactionplugin SVN_SILENT made messages (.desktop file) 2014-06-16 04:30:47 +00:00
icon New icon by Malcer <malcer@gmx.com> 2014-02-19 21:10:41 +01:00
interfaces Expose the icon name from the device instance 2014-06-14 19:42:34 +02:00
kcm Reorganize sources 2014-06-14 15:22:40 +02:00
kded Figure out Messages.sh after code refactoring 2014-06-17 18:45:47 +02:00
kio cmake fixes 2014-06-14 16:56:41 +02:00
plasmoid cmake fixes 2014-06-14 16:56:41 +02:00
plugins Figure out Messages.sh after code refactoring 2014-06-17 18:45:47 +02:00
tests Reorganize sources 2014-06-14 15:22:40 +02:00
.gitignore Initial commit 2013-06-06 05:57:06 +02:00
CMakeLists.txt Introduce a fileitemactionplugin 2014-06-14 19:42:33 +02:00
COPYING add missing licence file 2013-09-13 19:30:36 +02:00
README Documentation 2013-09-24 14:14:34 +02:00

Class diagram
==============

   Backend_1  ...  Backend_N
           \   |  /
            Daemon
           /   |  \
     Device_1  ...  Device_N
                   /         \
                   |-Plugin_1 |-DeviceLink_1
                   |-Plugin_2 |-DeviceLink_2
                   |- ...     |-...
                   |-Plugin_N |-DeviceLink_N


Daemon instantiates Backends

Backends manage to create DeviceLinks with the devices they can reach, and Q_EMIT them to the Daemon.

When the Daemon receives a DeviceLink from a backend:
    - If it already knows the Device, adds the new DeviceLink to the existing Device, as a new way to reach it.
    - If not, it creates a new untrusted (yet to be paired) Device.

Devices contain a list of DeviceLinks, plus a list of Plugins (instantiated automatically)

Information for and from Plugins is encapsulated in NetworkPackages.

When a DeviceLink receives a NetworkPackage from the device in the other end, Device will notify all the plugins.

When a Plugin wants to send a NetworkPackage, it does so using the pointer to Device



The NetworkPackage format
=========================

NetworkPackages are independent and self-contained pieces of information that
are sent from one device to another (via a DeviceLink) serialized in json.

The basic structure of a NetworkPackage is the following:

{
  "id": 123456789,
  "type": "org.kde.whatever",
  "body": {

   },
  "version": 5
}

Each type of package defines what it should contain inside its "body", so only
the emisor plugin and receiver plugin of this type of package need agree about
its content. Each plugin should provide a README explaining what does it write
in the "body" section, to ease porting to other platforms.

If the package has a payload attached, it will also contain two more fields:
 "payloadSize": The size of the file, or -1 if it is a stream without known end
 "payloadTransferInfo": Another JSON Object containing the information that the
                        backend wants to send to the peer backend, to actually
                        transfer the payload.

Encrypted network packages have the following format:

 "type": is always set to "kdeconnect.encrypted".
 "id": contains a new valid id (ie: not the same id as the unencrypted package).
 "version": contains the package version.
 "body": contains a "data" array that carries the original package encrypted.

The "data" array is filled the following way:

 1. The original package is serialized.
 2. The serialized string is divided in chunks small enough to be encrypted with
    the other device's public key.
 3. Each chunk is encrypted and appended to the array in order.