Plasma/conditionalQMLImports: Difference between revisions

From KDE Community Wiki
No edit summary
(more details)
Line 1: Line 1:
= Conditional imports =
= Conditional imports =
In order to restrict applications or components in general, a security mechanism is needed in Qt. The basic design should be the following:
== General Design ==
In order to restrict applications or components in general, a security mechanism is needed in Qt. This should be implemented in collaboration with upstream Qt The basic design should be the following:


* In the import code path, the import is either done right away (current case), or it uses an optional import policy agent, which checks if the application or component has sufficient privileges, and either allows or denies the import
* In the import code path, the import is either done right away (current case), or it uses an optional import policy agent, which checks if the application or component has sufficient privileges, and either allows or denies the import
* The policy agent is replacable, much like QNetworkAccessManager
* The policy agent is replaceable, much like QNetworkAccessManager: QQmlImportManager (?)
* import manager is kept minimal in Qt API, but flexible in reimplementation
* different policies for subsets of the scenegraph are possible, for example per plasmoid import restrictions
* detailed failure information import failures can be handled gracefully by the application
* import performance in current case should not suffer
* import performance in current case should not suffer


This obviously needs changes in Qt, and should be implemented in collaboration with upstream Qt.
On the Plasma side, this needs  
* signing of Plasmoids and other components (clients)
* permission validation extensions in imports metadata
* client UI for validation feedback in Plasma/Shell package
* an implementation of QQmlImportManager using the above parts
 
== Performance Measuring ==
Ideas for evaluating performance with or without import manager:
* instrument a minimal binary that loads a QML file, measure load performance, measure performance with and without overridden QQmlImportManager
* Generate 10000 files that each import a bunch of modules, put them in a ListView, model: 10000
* Dynamically create those components with a bit of javascript, measure loading performance

Revision as of 02:29, 2 May 2013

Conditional imports

General Design

In order to restrict applications or components in general, a security mechanism is needed in Qt. This should be implemented in collaboration with upstream Qt The basic design should be the following:

  • In the import code path, the import is either done right away (current case), or it uses an optional import policy agent, which checks if the application or component has sufficient privileges, and either allows or denies the import
  • The policy agent is replaceable, much like QNetworkAccessManager: QQmlImportManager (?)
  • import manager is kept minimal in Qt API, but flexible in reimplementation
  • different policies for subsets of the scenegraph are possible, for example per plasmoid import restrictions
  • detailed failure information import failures can be handled gracefully by the application
  • import performance in current case should not suffer

On the Plasma side, this needs

  • signing of Plasmoids and other components (clients)
  • permission validation extensions in imports metadata
  • client UI for validation feedback in Plasma/Shell package
  • an implementation of QQmlImportManager using the above parts

Performance Measuring

Ideas for evaluating performance with or without import manager:

  • instrument a minimal binary that loads a QML file, measure load performance, measure performance with and without overridden QQmlImportManager
  • Generate 10000 files that each import a bunch of modules, put them in a ListView, model: 10000
  • Dynamically create those components with a bit of javascript, measure loading performance