Enablers: Interprocess Communication (IPC): Data Sharing
Functional Description

Qt Extended Data Sharing (QDS) provides an API to efficiently share and process data between applications, and provides mechanisms for finding and interacting with applications which provide desired QDS services.

Features

• Data Sharing

Data Sharing

Qt Extended Data Sharing (QDS) provides an API to efficiently share and process data between applications, and provides mechanisms for finding and interacting with applications which provide desired QDS services. For example an application may want to display a street map for a location, instead of doing the conversion itself the application can search for a QDS service which takes a street address and returns an image of the street map.

QDS is a form of remote procedure call, layered on top of Qt Extended services, which is optimized for data processing and sharing. QDS encapsulates data into a typed data object (QDSData) which is provided with the request, the response or both. QDS models the procedure call as an action. Actions are invoked in applications to request a service from an application which provides a QDS service. The provider then handles the action request and responds with any data.

QDS allows applications to share data in an efficient manner. Although it is similar to QDL, it differs in that the data is not application specific, and can therefore be rendered by any application efficiently.

The elements of QDS are as follows:

• Client Application - application which wishes to share data from, or modify data in, another application.
• Source Application - application which provides one or more QDS services.
• QDS Database - The central repository for shared data. For the core phase the database stores the data alongside a MIME type using a QUid as the key. In the extended phase a reference count is included for each entry.

QDS operates in a manner similar to QDL, in that it uses QCop messages to request and receive shared data. The difference is that the client application receives a key which locates the data in the QDS database instead of an exact copy of the data. This mechanism is more efficient as storing the data in a central location reduces duplication and allows the data to be easily updated and managed.

It is impossible for QDS to impose certain behavior as it is application specific, this includes:

• How the client selects the source application - In some cases, the source application to choose is obvious, e.g. user wishes to add a photo to a contact, but in other scenarios it is less obvious. It is up to the client application to decide how this is done.
• How the source application allows the user to select the data source - Typically the source application will decide how to present the available data to the user based off the mimetype in the requestData message.
• How the source application stores the QUids of shared data - Ideally a source application associates the QUniqueId with the data source, then if another request is made for the same data, only one entry is needed in the QDS database for the data item.
• How the client application stores the QUids of shared data - There are no requirements on how the client stores the QUniqueId.
• How the client application renders the data