(sorry for interjecting a reply to multiple emails here, but i just got back on this list specifically to discuss QML matters.)
On Tuesday, December 11, 2012 14:21:28 Laszlo Papp wrote: > On Tue, Dec 11, 2012 at 1:11 PM, Knoll Lars <[email protected]> wrote: > > On Dec 11, 2012, at 5:30 AM, Thiago Macieira <[email protected]> > > > code (QML files only), then this might work. But, to be honest, is this > > > a > > > realistic use-case? If we want a QML runtime, won't the platform want to > > > > allow > > > > > 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. > > For a runtime, I believe we need to find different ways in any case. Maybe > > a packaged QML app bundle could somehow contain a manifest file containing > > the plugins it uses. Trying to load any other plugin would then be > > rejected > > by the runtime. > > Agree, but nitpick: rather credentials, that can be requested, than plugin > names. So, in Plasma w ealready have packages of QML and they have manifest files and they define which resources they would like to access (both required and optional, allowing for graceful degredation in the face of unavailability). Basically, what has been suggested here, and this works fine, except for QML imports which offer us no facility to control the imports. Currently we map which of these packages are allowed to access which kinds of resources, and that's what is needed here. The rest is implementation details that are likely to be platform specific. Or, I suppose, a QML runtime could adopt one method (such as the method described above, which is used in Plasma and which is similar to how widgets have been done on other platforms out there) .. regardless .. a way for the platform to enforce the policy is needed. This is not something that the QML runtime can implement fully on its own as the permissions model is unlikely to be universal. -- Aaron J. Seigo
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
