On Tue, Dec 11, 2012 at 7:52 AM, Thiago Macieira <[email protected]> wrote: > On terça-feira, 11 de dezembro de 2012 15.44.37, Aaron J. Seigo wrote: >> > > > loading of native plugins from the application? >> >> Yes, but not native plugins installed by the QML applications. In such a >> situation we need to be able to ensure that applications which say "I will >> access this list of plugins" only do so. >> >> Is this realistic? It is precisely what we've been doing for a number of >> years in Plasma. >> >> > > I tend to agree with Thiago. How does restricting this help for native >> > > apps? It's anyway the app itself setting the restrictions. >> >> Well, yes, it doesn't help for "native" apps. That's not the point, is it? >> Because some kinds of applications will not benefit from this does not mean >> that those which would should not have a facility to use to accomplish it. > > It seemed to me that it was as well. > > I'm not doubting the benefit of this for controlling what a plugin in QML > does. > I was just questioning the use of this feature to enforce device and platform > security. It's the wrong level.
Correct, this is not a complete device and platform solution. The idea though is that this could be used when implementing a complete device and platform solution, because that complete solution on a lower level may need to have an answer for QML too. If your runtime runs qml directly you may want to restrict its ability to call native code (because everything QML does is exposed native code). Here are a couple of examples to clarify when this might be used: A) Creating a mobile platform that can have native executables deployed to it. Here you need a lower level security control anyways, you probably won't use this. B) Creating a mobile platform that is locked-down and does not allow 3rd party executables. All 3rd party applications must be QML files. Here you might be able to use import control to prevent loading of 3rd party executables entirely. C) Creating an application platform that accepts QML scripting for part of the UI or data. QML is a great language for your usecase, but you only want 3rd party scripts to render graphics within their little box and call application specific functionality. You do not want it to create new windows, you do not want it to have access to the command line arguments, and you do not want to let it draw particles (because that would really show up your UI ;) ). In this case this kind of API would be exactly what you need in order to have a powerful embedded scripting engine without endangering your app. -- Alan Alpert _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
